Today I did an upgrade on ConfigMgr Current Branch from version 1602 to 1606. During the upgrade I choose to validate the client package in pre-production first. After the upgrade however, there was no possiblity to promote the ConfigMgr client to the latest version. I restarted the ConfigMgr server and console, but without any luck. After that I decided to install Update Rollup 1, which was successful again, but still the same behaviour. No possibility to promote the ConfigMgr client to the latest version again.
Lucky me I found the following thread: Microsoft TechNet
It mentioned: I solved my problem. It seems to be a RBAC problem. The user I used in ConfigMgr was "Full Administrator" but assigned though an AD group and not directly assigned. When I added my user directly as a user account in the ConfigMgr console and gave him "Full Administrator" rights then I could promote the client to production.
In my case (customer location) this was the same situation. The user which did the upgrade and was logged on is part of an security group. That's a nasty situation for sure! Long story short: I added the user directly as Full Administrator in the console, and the "Promote Pre-production Client" button became available again. Hope that Microsoft will fix this for future builds, because adding users instead of groups is not the way to go. Hope it helps!
Showing posts with label ConfigMgr client. Show all posts
Showing posts with label ConfigMgr client. Show all posts
Monday, September 12, 2016
Unable to promote pre-production client in ConfigMgr Current Branch
Tuesday, June 30, 2015
Include ConfigMgr Client Cumulative Update during OSD
During deployment in ConfigMgr, you can install the ConfigMgr Client Cumulative Update immediately. There are multiple posts found where the PATCH= parameter is used. The Cumulative Update needs to be in a package or reference image (included for installation) for this. I see lots of times the PATCH= parameter is skipped, for different reasons. Let's have a look at another way to install the Cumulative Update. This one is not hard at all. It just works :-)
Just create ClientPatch folders in both ConfigMgr Client locations:
-Program Files\Microsoft Configuration Manager\Client\x64
-Program Files\Microsoft Configuration Manager\Client\i386
and copy the appropriate architecture (x64 and/or i386) from your hotfix to one of this folders. Do not forget to update your ConfigMgr Client Package to be sure using the Files with the Hotfixes.
That's it! No PATCH= parameter needed at all. It did work on my first try (CU4), so very easy to use if you ask me :-)
When using Client Push Installation it will be helpfull either. No need to apply the CU client update afterwards. It will be detected automatically:
-Detected 1 client patch files. Will apply them after client installation.
-Adding file 'configmgr2012ac-r2-kb3026739-x64.msp' to BITS job, saving as 'C:\Windows\ccmsetup\configmgr2012ac-r2-kb3026739-x64.msp'.
-C:\Windows\ccmsetup\configmgr2012ac-r2-kb3026739-x64.msp is Microsoft trusted.
-File C:\Windows\ccmsetup\configmgr2012ac-r2-kb3026739-x64.msp installation succeeded.
-Params to send FSP message '5.0.7958.1501 Deployment [DP]
Why this is a hidden/undocumented feature suprised me.
Can't be easier if you ask me :-)
Source: SCCMfaq.ch
Source: Systems Management and Automation
Update 6-7:
@jarwidmark - That method works for some, breaks for some, but either way, it is totally unsupported by Microsoft.
@rsjulsen - This method has totally worked for me :) But ofc.. Totally unsupported.. and totally, totally awsome :)
Update 24-8:
With Cumulative Update 1 for ConfigMgr 2012 R2 SP1 and 2012 SP2 this isn't needed anymore. Source: Automatically updating the Configuration Manager client
Just create ClientPatch folders in both ConfigMgr Client locations:
-Program Files\Microsoft Configuration Manager\Client\x64
-Program Files\Microsoft Configuration Manager\Client\i386
and copy the appropriate architecture (x64 and/or i386) from your hotfix to one of this folders. Do not forget to update your ConfigMgr Client Package to be sure using the Files with the Hotfixes.
That's it! No PATCH= parameter needed at all. It did work on my first try (CU4), so very easy to use if you ask me :-)
When using Client Push Installation it will be helpfull either. No need to apply the CU client update afterwards. It will be detected automatically:
-Detected 1 client patch files. Will apply them after client installation.
-Adding file 'configmgr2012ac-r2-kb3026739-x64.msp' to BITS job, saving as 'C:\Windows\ccmsetup\configmgr2012ac-r2-kb3026739-x64.msp'.
-C:\Windows\ccmsetup\configmgr2012ac-r2-kb3026739-x64.msp is Microsoft trusted.
-File C:\Windows\ccmsetup\configmgr2012ac-r2-kb3026739-x64.msp installation succeeded.
-Params to send FSP message '5.0.7958.1501 Deployment [DP]
Why this is a hidden/undocumented feature suprised me.
Can't be easier if you ask me :-)
Source: SCCMfaq.ch
Source: Systems Management and Automation
Update 6-7:
@jarwidmark - That method works for some, breaks for some, but either way, it is totally unsupported by Microsoft.
@rsjulsen - This method has totally worked for me :) But ofc.. Totally unsupported.. and totally, totally awsome :)
Update 24-8:
With Cumulative Update 1 for ConfigMgr 2012 R2 SP1 and 2012 SP2 this isn't needed anymore. Source: Automatically updating the Configuration Manager client
Labels:
ConfigMgr client,
CU1,
CU2,
CU3,
CU4,
Cumulative Update,
Hotfix,
Parameter,
PATCH=
Tuesday, January 27, 2015
ConfigMgr 2007 Standard distribution point migration
During a ConfigMgr 2007 distribution point migration IIS must be installed (if it isn't installed yet) and content can be converted. Because of IIS installation (which ConfigMgr will do for you, if you select this in the wizard) a restart may be triggered. In my case an unexpected restart was done on a Windows Server 2008 R2 system. This because of an "unknown" MSI installation. As far as I can see only the "Remote Differential Compression" (RDC) feature is installed and the "Microsoft Visual C++ 2010 x64 redistributable".
When distribution points are not "eligible for upgrade", which they were in my case, just make sure no other roles (eg PXE service point) then distribution point are installed. Just make sure there is enough available disk space also - need 100% free space in order to carry out conversion to ConfigMgr 2012 content library. When removing PXE service point, clean up disk space, and wait a while (or reboot the server), distribution points are finally eligible for upgrade.
Source: Microsoft TechNet
When looking in SMS_DP$\SMS\BIN\vcredist.log-MSI_vc_red.msi on the server the following lines are displayed:
MSI (s) (68:4C) [10:55:25:452]: Note: 1: 1707 MSI (s) (68:4C) [10:55:25:452]: Product: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219 -- Installation completed successfully.
MSI (s) (68:4C) [10:55:25:452]: Windows Installer installed the product. Product Name: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Installation success or error status: 0.
MSI (s) (68:4C) [10:55:25:452]: Value of RebootAction property is MSI (s) (68:4C) [10:55:25:452]: Windows Installer requires a system restart. Product Name: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Type of System Restart: 2. Reason for Restart: 1.
MSI (s) (68:4C) [10:55:25:452]: Product: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Restart required. The installation or update for the product required a restart for all changes to take effect. The restart was deferred to a later time.
MSI (s) (68:4C) [10:55:25:468]: Deferring clean up of packages/files, if any exist MSI (s) (68:4C) [10:55:25:468]: MainEngineThread is returning 3010 MSI (s) (68:34) [10:55:25:468]: RESTART MANAGER: Session closed.
MSI (s) (68:34) [10:55:25:468]: No System Restore sequence number for this installation.
When looking in Event Viewer the server is rebooted a second afterwards (on 10:55:26 exactly):
The process f:\06ce98a1da047515c72afeca1f47e3\Setup.exe (########) has initiated the restart of computer ######## on behalf of user ######## for the following reason: Other (Planned) Reason Code: 0x80000000 Shutdown Type: restart
So yes, "Microsoft Visual C++ 2010 x64 redistributable" did need a restart, and your server will be down for a few moments.
Furthermore Microsoft TechNet mentions that the ConfigMgr 2007 client must be removed on Branch distribution points only. During migration on a Standard distribution point however the following message is displayed "Failed to update binaries". After removing the ConfigMgr 2007 client, converting content was done successfully without any problem. When migrating packages is done, the following message is displayed: "Completed reassign distribution point". So next time, I will remove the ConfigMgr 2007 client on Standard distribution points before migration also.
Be aware that only packages which are migrated to ConfigMgr 2012 will be converted to the SCCMContentLib folder. Other old packages will still be left in the old package share folder and can be removed afterwards manually. Just make sure that packages migrated does not have the "Copy the content in this package to a package share on distribution points" have selected in properties. Otherwise they will be on your new ConfigMgr 2012 server in package share folder also. After that you will have new distribution points running!
Source: Microsoft TechNet
When distribution points are not "eligible for upgrade", which they were in my case, just make sure no other roles (eg PXE service point) then distribution point are installed. Just make sure there is enough available disk space also - need 100% free space in order to carry out conversion to ConfigMgr 2012 content library. When removing PXE service point, clean up disk space, and wait a while (or reboot the server), distribution points are finally eligible for upgrade.
Source: Microsoft TechNet
When looking in SMS_DP$\SMS\BIN\vcredist.log-MSI_vc_red.msi on the server the following lines are displayed:
MSI (s) (68:4C) [10:55:25:452]: Note: 1: 1707 MSI (s) (68:4C) [10:55:25:452]: Product: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219 -- Installation completed successfully.
MSI (s) (68:4C) [10:55:25:452]: Windows Installer installed the product. Product Name: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Installation success or error status: 0.
MSI (s) (68:4C) [10:55:25:452]: Value of RebootAction property is MSI (s) (68:4C) [10:55:25:452]: Windows Installer requires a system restart. Product Name: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Type of System Restart: 2. Reason for Restart: 1.
MSI (s) (68:4C) [10:55:25:452]: Product: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Restart required. The installation or update for the product required a restart for all changes to take effect. The restart was deferred to a later time.
MSI (s) (68:4C) [10:55:25:468]: Deferring clean up of packages/files, if any exist MSI (s) (68:4C) [10:55:25:468]: MainEngineThread is returning 3010 MSI (s) (68:34) [10:55:25:468]: RESTART MANAGER: Session closed.
MSI (s) (68:34) [10:55:25:468]: No System Restore sequence number for this installation.
When looking in Event Viewer the server is rebooted a second afterwards (on 10:55:26 exactly):
The process f:\06ce98a1da047515c72afeca1f47e3\Setup.exe (########) has initiated the restart of computer ######## on behalf of user ######## for the following reason: Other (Planned) Reason Code: 0x80000000 Shutdown Type: restart
So yes, "Microsoft Visual C++ 2010 x64 redistributable" did need a restart, and your server will be down for a few moments.
Furthermore Microsoft TechNet mentions that the ConfigMgr 2007 client must be removed on Branch distribution points only. During migration on a Standard distribution point however the following message is displayed "Failed to update binaries". After removing the ConfigMgr 2007 client, converting content was done successfully without any problem. When migrating packages is done, the following message is displayed: "Completed reassign distribution point". So next time, I will remove the ConfigMgr 2007 client on Standard distribution points before migration also.
Be aware that only packages which are migrated to ConfigMgr 2012 will be converted to the SCCMContentLib folder. Other old packages will still be left in the old package share folder and can be removed afterwards manually. Just make sure that packages migrated does not have the "Copy the content in this package to a package share on distribution points" have selected in properties. Otherwise they will be on your new ConfigMgr 2012 server in package share folder also. After that you will have new distribution points running!
Source: Microsoft TechNet
Tuesday, January 6, 2015
How to increase the ConfigMgr client cache on existing and new systems
By default the ConfigMgr client cache on systems is 5120MB, which is 5GB. When deploying lot of packages this isn't enough for sure. Because content remains in the cache for at least 24 hours, it cannot be overwritten by new content if it requires the space. When it's needed to deploy more then 5GB within 24 hours, the client cache must be expanded (or cleaned up). When the client must download new packages, you can either increase the client cache size or choose the delete option within the control panel applet of the client to delete contents of the cache. Let's have a look at the possibilities.
Expand the ConfigMgr client cache manually:
-You can change this setting directly on the client itself using the Control Panel applet > Cache > Configure Settings.
Expand the ConfigMgr client cache on existing systems:
-Just create a package with VBS file to change cache size:
====================
On Error Resume Next
Dim UIResManager
Dim Cache
Dim CacheSize
CacheSize=10240
Set UIResManager = createobject("UIResource.UIResourceMgr")
Set Cache=UIResManager.GetCacheInfo()
Cache.TotalSize=CacheSize
====================
Expand the ConfigMgr client cache on new systems:
-Use SMSCACHESIZE=10240 to the "Setup Windows and ConfigMgr" step in the task sequence used for deployment.
-Use CCMSetup.exe SMSCACHESIZE=10240 when starting the ConfigMgr client installation manually.
Sources:
-Microsoft TechNet
-TechNet Blogs
Expand the ConfigMgr client cache manually:
-You can change this setting directly on the client itself using the Control Panel applet > Cache > Configure Settings.
Expand the ConfigMgr client cache on existing systems:
-Just create a package with VBS file to change cache size:
====================
On Error Resume Next
Dim UIResManager
Dim Cache
Dim CacheSize
CacheSize=10240
Set UIResManager = createobject("UIResource.UIResourceMgr")
Set Cache=UIResManager.GetCacheInfo()
Cache.TotalSize=CacheSize
====================
Expand the ConfigMgr client cache on new systems:
-Use SMSCACHESIZE=10240 to the "Setup Windows and ConfigMgr" step in the task sequence used for deployment.
-Use CCMSetup.exe SMSCACHESIZE=10240 when starting the ConfigMgr client installation manually.
Sources:
-Microsoft TechNet
-TechNet Blogs
Labels:
5120,
5120MB,
Cache,
Client,
Client Cache,
ConfigMgr client,
SCCM client,
SMSCACHESIZE
Subscribe to:
Posts (Atom)


