Last month I did a ConfigMgr upgrade from SP1 to R2, with Cumulative Update 4 afterwards. At first sight everything seems to be okay. After a few weeks however, customer was mentioning OSD was very slow at Driver package and ConfigMgr client stage installation. Default deployment before the R2 upgrade was around 45 minutes, but after R2 upgrade around 135 minutes! Lucky me I found the following post on Microsoft TechNet HERE and HERE.
It mentions:
It appears that MS support was able to find a solution for my environment.
Immediately after enabling the "allow clients to connect anonymously" setting on each distribution point the time it took for the MDT Toolkit package to download went from 30 minutes to around 20 seconds.
The support tech was unable to explain why this setting was required following the R2 upgrade in our environment. He verified that in his lab environment he did NOT have this setting configured on the DP and he saw no issue downloading the MDT toolkit package.
As much as I would like to have a root cause for this issue I'm just happy that my OSD process isnt taking 3 hours now!
At customer mentioned this was the solution also. Immediately after enabling the "Allow clients to connect anonymously" setting on each distribution point configured, deployment was done in 45 minutes again. Strange enough I did a lot of R2 installations, and a lot of SP1 to R2 upgrades also, but never had this issue before. Still happy with this easy to implement solution. Thanks again!
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
Last week I installed multiple remote distribution points on Windows Server 2008 R2 systems. The installation went to be fine, but no files were replicated on disk. This because of multiple distribution errors, which can be found in the distmgr.log:
-CSendFileAction::AddFile failed; 0x80041001
-CSendFileAction::SendFiles failed; 0x80041001
I did choose "Install and configure IIS if required by Configuration Manager" during installation, but IIS was installed already on servers. I did install BITS on servers also, because this seems to be needed (installation can be failing otherwise). Strange thing, because BITS is no prerequisite at all? What I did NOT however is installing RDC as a prerequisite. Therefore files couldn't be replicated after all.
Note: With System Center 2012 Configuration Manager, the distribution point site system role does not require Background Intelligent Transfer Service (BITS). When BITS is configured on the distribution point computer, BITS on the distribution point computer is not used to facilitate the download of content by clients that use BITS.
Note: The Remote Differential Compression (RDC) feature is a set of application programming interfaces (APIs) that applications can use to determine if a set of files have changed, and if so, to detect which portions of the files contain the changes. RDC detects insertions, removals, and rearrangements of data in files, which enables an application to replicate only the changed portions of a file. This is useful when replicating files over a limited-bandwidth network such as a wide area network (WAN) connection.
Let's have a look for all prerequisites also, for a distribution point you need:
- Application Development (IIS)
- Security (IIS)
- IIS 6 Management Compatibility (IIS)
- IIS 6 Metabase Compatibility
- IIS 6 WMI Compatibility
- BITS (feature)
- RDC (feature)
Source: Supported Configurations for Configuration Manager
In ConfigMgr packages on a Distribution Point are placed on the drive with most free space. Sometimes this can be the System drive also. This can be prevented by using a hidden file. More about that can be found here: Controlling Configuration Manager 2012 Using Hidden Files. But what to do when the Distribution Point is already placed on the wrong drive? Just follow steps in this blogpost for that.
Assuming that you're using ConfigMgr 2012 SP1, just download "System Center 2012 Configuration Manager Service Pack 1 Component Add-ons and Extensions". When installed open "Tools Command Prompt" and go into the ServerTools folder. Enter ContentLibraryTransfer.exe -SourceDrive <current drive letter> -TargetDrive <new drive letter>. For Example: ContentLibraryTransfer.exe -SourceDrive C -TargetDrive D
It will take a while (depending of the size on the Distribution Point) but the tool will do ALL for you. Just wait till it's ready and you're done. Much easier then with ConfigMgr 2007 a long time ago ;)
After copying data, SCCM services are stopped, DP shares are deleted, Permissions are set, WMI and Registry is updated, SCCM services are started again, old DP content is removed, and virtual directories are updated. All is done by the tool, so no worry about that. Quite cool that one single tool and command is doing ALL for you.
Hope it helps!
When installing a Distribution Point (DP) during ConfigMgr installation, it will be placed on the disk with the most free diskspace. When you install it afterwards a selection of disks can be choosed. Even better is to place a NO_SMS_ON_DRIVE.SMS file on all drives where you don't want a DP. They will be excluded next time.
When the DP is already installed on the wrong drive or when it must be moved to another location, ContentLibraryTransfer.exe can be used.
ContentLibraryTransfer.exe is a tool that will move a distribution point’s content store from one drive to another. That's it, and it is a very simple process.
The syntax used with the tool is – ContentLibraryTransfer.exe –SourceDrive <Current Drive Letter> -TargetDrive <New Drive Letter>
The ContentLibraryTransfer.exe respects NO_SMS_ON_DRIVE.SMS files. In other words if the drive specified as the TargetDrive contains a NO_SMS_ON_DRIVE.SMS the ContentLibraryTransfer.exe will not copy the content library to this drive.
More information on this can be found on MS TechNet.
When installing ConfigMgr 2007 with all default roles on the local server, you must decide on which drive the Distribution point (share) will be placed.
Without any configuration the Distribution point share will be placed on the drive with the most free space. When after a while of time there is more free space on another drive, new packages will be placed on that drive. Then a new Distribution point share will be created, and software packages will be on multiple drives. This is not very handy for manage your ConfigMgr 2007 environment.
In the Software Distribution properties (Site Management - Component Configuration) there can be a default "Location of stored packages" set. Here will be the first packages stored. This is no guarantee that all packages that will added later, will be placed on the same share! To do this a workaround is available, that works also with (older) SMS 2003 environments.
Create a new txt file on all drives where you don't want a Distribution point share, and name it "no_sms_on_drive.sms". That way you make the above setting mandatory for the default "Location of stored packages". Much better that way to decide where to put the packages!
In my environment it will looks like this:
No Distribution point share (and packages) will be placed on the C:\ drive!
No Distribution point share (and packages) will be placed on the D:\ drive!
The Distribution point share (and ALL packages) will be placed on the E:\ drive! Here will be the SMSPKG folder stored, and all packages will be on the same drive. All content folders are stored on the D:\ drive this way (beneath the SCCM folder).
Hope to helped you with this (easy) solution!
