skip to main |
skip to sidebar
When trying to provision updates using the ConfigMgr Console of System Center Configuration Manager 2007 (R2 SP2 in my case, but it also applies to earlier versions) you can get the following error in the process screen of the Update List Wizard.
The process is not in background processing mode
Now what? Background processing mode makes you think it's because of BITS being used. Well, you're right. This is the way you can resolve this issue.
1. Login to your WSUS Server.
2. Stop the BITS Service (through Services.msc or net stop bits at a commandline)
3. Stop the Automatic Updates Service (through Services.msc or net stop wuauserv at a commandline)
4. Browse to: Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader
Note: If you're using Windows Server 2008 or Server 2008 R2 the Application Data folder is a junction point which has deny list permissions set to Everyone. If you need to be able to browse this folder you need to remove these NTFS permissions.
5. In the \Downloader folder delete the files qmgr0.dat and qmgr1.dat. These files will be recreated once you start the BITS service.
6. In the C:\Windows\ directory delete the folder SoftwareDistribution This folder will be recreated once you start the Automatic Updates service.
7. Start the Automatic Updates service using services.msc or by using net start wuauserv
8. Start the BITS service using services.msc or by using net start bits
9. Go into the ConfigMgr Console and go to Software Updates and right click on Software Repository. Choose Run Synchronisation.
Now you're able to download the updates again. I hope this helps.
Regards,
Stefan Hazenbroek
I just recieved the following email from Microsoft Learning:
Congratulations on earning your Enterprise Messaging Administrator 2010 certification! We hope you enjoy the benefits of your certification and of membership in the Microsoft Certified Professional community.
Now that's a message you like to hear in the early morning!
And we have another one!
In my testlab I have WSUS setup on the same server as the SCCM Site Server. However, when trying to setup the Active SUP I got the following error in the WSYNCMGR.log
SMS WSUS Synchronization failed. Message: WSUS server not configured. Source: CWSyncMgr::DoSync. The operating system reported error 2147500037: Unspecified error
From this message it looks as if WSUS could not be contacted, but the WSUSCtrl.log states that all connections to the WSUS server are succesful. After searching around it seemed that this issue was due to the fact of WSUS and the SCCM Site Server being on the same machine. The fix is as follows (also check out http://support.microsoft.com/kb/896861 for more information (choose Method 1)):
1) Fire up regedit.
2) Go to HKLM\System\CurrentControlSet\Control\LSA
3) Create a new DWORD value called DisableLoopbackCheck
4) Edit the value and in the Value Data box type 1
5) Close regedit
6) In the SCCM Console right-click on Update Repository and check the WSYNCMgr.log for any issues.
In my case this fixed my issues.
I've been reinstalling my testenvironment to support Windows Server 2008 R2 instead of Windows Server 2008, but while installing SCCM 2007 R2 SP2 I ran into the following problem:
SMS Site Component Manager failed to install component SMS_MP_CONTROL_MANAGER on server.
The WebDAV server extension is either not installed or not configured properly.
Solution: Make sure WebDAV is installed and enabled. Make sure there is an authoring rule that allow “All users” read access to “All content”. Make sure the WebDAV settings “Allow anonymous property queries” and “Allow property queries with infinite depth” are set to “true” and “Allow Custom Properties” is set to false.
Now what? I am 100% sure I have the correct settings in WebDAV (according to the log also) but it doesn't seem to recognize it. After doing some searching on the internet I found the location of the configuration file of Webdav. This file is located in: C:\Windows\System32\inetsrv\config\schema\WebDAV_schema.xml. After opening this file up I noticed that the settings in this file were different from the settings I changed in the IIS Manager.
The settings were configured as:
<attribute name=”allowAnonymousPropfind” type=”bool” defaultValue=”false” />
<attribute name=”allowInfinitePropfindDepth” type=”bool” defaultValue=”false” />
<attribute name=”allowCustomProperties” type=”bool” defaultValue=”true” />
However they should be:
<attribute name=”allowAnonymousPropfind” type=”bool” defaultValue=”true” />
<attribute name=”allowInfinitePropfindDepth” type=”bool” defaultValue=”true” />
<attribute name=”allowCustomProperties” type=”bool” defaultValue=”false” />
After correcting these settings (remember you have to take ownership of the file to be able to change it) and restarting the World Wide Web Publishing Service and the SMS_SITE_COMPONENT_MANAGER the Management Point gets installed correctly. You can check if the installation is succesful in the logfile MPSetup.log in your SCCM\Logs directory. If succesful the log looks like this:
<01-16-2010 22:08:36> ======== Completed Installation of Pre Reqs for Role SMSMP ========
<01-16-2010 22:08:36> Installing the SMSMP
<01-16-2010 22:08:36> Passed OS version check.
<01-16-2010 22:08:36> IIS Service is installed.
<01-16-2010 22:08:36> checking WebDAV configuraitons
<01-16-2010 22:08:37> WebDAV is configured
<01-16-2010 22:08:37> No versions of SMSMP are installed. Installing new SMSMP.
<01-16-2010 22:08:37> Enabling MSI logging. mp.msi will log to C:\Program Files (x86)\Microsoft Configuration Manager\logs\mpMSI.log
<01-16-2010 22:08:37> Installing C:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\mp.msi CCMINSTALLDIR="C:\Program Files (x86)\SMS_CCM" CCMSERVERDATAROOT="C:\Program Files (x86)\Microsoft Configuration Manager" USESMSPORTS=TRUE SMSPORTS=80 USESMSSSLPORTS=TRUE SMSSSLPORTS=443 USESMSSSL=TRUE SMSSSLSTATE=0 CCMENABLELOGGING=TRUE CCMLOGLEVEL=1 CCMLOGMAXSIZE=1000000 CCMLOGMAXHISTORY=1
<01-16-2010 22:08:57> mp.msi exited with return code: 0
<01-16-2010 22:08:57> Verifying CCM_CLIENT virtual directory.
<01-16-2010 22:08:57> Website path is IIS://LocalHost/W3SVC/1.
<01-16-2010 22:08:57> Connecting to IIS.
<01-16-2010 22:08:57> CCM_CLIENT is currently C:\Program Files (x86)\Microsoft Configuration Manager\Client.
<01-16-2010 22:08:57> Installation was successful.
One last thing. When creating a backup of the WebDav_schema.xml, do not create the backup in the same directory as the original file. All .xml files put in this directory will be read by IIS so your settings will not seem changed afterwards.
Good luck, I hope this helps.
Windows Server 2008 R2 Core offers the possibility of installing a Certificate Authority. However, not much documentation is available on how to configure the role using the commandline.
In this blogpost I will explain how you can install the role and use it to issue certificates to your servers and clients.
Log in to the server (Windows Server 2008 R2 Server Core server) that you're going to install the Certification Authority on. You need Domain Admin or equivalent permissions on a single forest, single domain infrastructure or Enterprise Admins on a multi-domain infrastructure to be able to install AD Certificate Services correctly. The following command has to be issued on the commandline:
Dism /online /enable-feature /featurename:CertificateServices
Don't forget, the DISM command is Case-Sensitive, so you should keep the Capitcal C and S in mind.
Instead, if you have powershell installed on your Windows Server 2008 R2 Core machine you can also use the following commands to install the role:
First, fire up powershell by typing powershell in the cmd screen. When Powershell is fired up type:
Import-Module ServerManager
At the top of the screen you'll see the module being imported, when it's complete you have the possibility to use the CMDLets Add-WindowsFeature,Get-WindowsFeature and Remove-WindowsFeature. Install AD Certificate Services using the following command:
Add-WindowsFeature ADCS-Cert-Authority
Restart the server when the installation is completed to be sure that all needed information is correctly populated and login to the server again.
Now, the nice folks over at the PKI blog published a nice article on how to use a VBScript to install a Certificate Authority. Check out:
http://blogs.technet.com/pki/archive/2009/09/18/automated-ca-installs-using-vb-script-on-windows-server-2008-and-2008r2.aspx
Download the script from above link and place it somewhere you are able to access it from the machine the CA is running on. Browse to the directory you placed the script in and execute the following command to install an Enterprise Root Certification Authority:
Cscript setupca.vbs /ie /sn NameOfYourCA /sk 4096 /sp "RSA#Microsoft Software Key Storage Provider" /sa SHA256
When you've issued above script and it completed succesfully (it'll take about a minute or so) you will be able to start your CA. Go to the Windows 7 workstation with RSAT installed and open up Computer Management. Browse to the machine your CA is running on and fire up the service Active Directory Certificate Services. When running this from the commandline you issue the name CertSvc.
On the RSAT machine, open up the Certification Authority shortcut in the Administrative Tools folder. When you open this shortcut you'll receive the following error:
This is no problem. Click on OK and when in the MMC right click Certification Authority (Local). In the submenu you choose Retarget Certification Authority. Choose Another Computer in the wizard and fill in the hostname of the machine that is running your CA. From now on you can manage your Certification Authority from your machine with RSAT installed.
