Bloggy McBlogface

If you have issues with SCCM deployed software updates failing to download and install, try checking the UpdatesHandler.log file (I recommend using trace32.exe with the SCCM Toolkit).

The particular problem I experienced, resulted in the following lines being written to the UpdatesHandler log: –

Unable to get locations, no need to continue with download

CBundledUpdate — Failed to download update (1a5ada44-c5cd-11de-a7e1-001372775900). Error = 0x80040669

CDeploymentJob — Failed to download update (1a5ada43-c5cd-11de-a7e1-001372775900). Error = 0x80040669

Note that these are seperate log entries, and are not written consequetively.

In this case, expand the Software Updates node in the appropriate Deployment Package in which the update is stored, locate the failed update and click on the Content Information tab (there will most likely be multiple updates with the name Article ID for different operating systems).

Individually selecting each of the updates that match the Article ID, ensure that all of the relevant files with unique Content IDs are marked as downloaded (i.e. in the Downloaded column it reads Yes).

There may be Content IDs for different languages, and these can be ignored.

If there are records with unique Content IDs that are not downloaded, the update should be re-downloaded and re-deployed using the usual method.

A code signing certificate is a security measure designed to assist in the prevention of malicious code execution. The intention is that code must be “signed” with a certificate that is trusted by the machine on which the code is executed. The trust is verified by contacting the certification authority for the certificate, which could be either a local (on the machine itself, such as a self-signed certificate), internal (on the domain, such as an enterprise certification authority) or external certification authority (third party, such as Verisign or Thawte).

For an Active Directory domain with an enterprise root certification authority, the enterprise root certification authority infrastructure is trusted by all machines that are a member of the Active Directory domain, and therefore any certificates issued by this certification authority are automatically trusted.

In the case of code signing, it may be necessary also for the issued certificate to be in the “Trusted Publishers” store of the local machine in order to avoid any prompts upon executing code, even if the certificate was issued by a trusted certification authority. Therefore, it is required to ensure that certificates are added to this store where user interaction is unavailable, such as running automated processes that call signed code.

A certificate can be assigned to a user or a computer, which will then be the “publisher” of the code in question. Generally, this should be the user, and the user will then become the trusted publisher. As an example, members of the development team in your organisation will probably each have their own code signing certificate, which would all be added to the “Trusted Publishers” store on the domain machines. Alternatively, a special domain account might exist specifically for signing code, although one of the advantages of code signing is to be able to determine the person who signed it.

The processes below details the steps required to generate a code signing certificate, export the certificate and private key, and import the certificate to a local machine or to a group of machines through the use of group policy.

Creating the Code Signing Certificate Template

1. Open the “Certification Authority” console on the enterprise root certification authority
2. Click on “Certificate Templates” and check if a template called “Code Signing” exists (if it already exists, there are no further steps required for this section)
3. If the “Code Signing” template does not exist, right click on the “Certificate Templates” node and select “New” -> “Certificate Template to Issue”
4. Select “Code Signing” and click OK

Generating the Code Signing Certificate

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “My user account” when prompted)
3. Expand “Personal”, right click on “Certificates” and select “All Tasks” -> “Request New Certificate”
4. Select “Active Directory Enrollment Policy”
5. Tick “Code Signing” and then click on the “Details” button to the right hand side of the “Code Signing” option
6. Click on “Properties”
7. Click on the “Private Key” tab, and then expand the “Key Options” section
8. Tick “Make private key exportable” and “Strong private key protection”
9. Click OK and then click the “Enroll” button (a message may appear stating that an application is creating a protected item – click OK to acknowledge this message)

Exporting the Certificate for Publishing

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “My user account” when prompted)
3. Expand “Personal”, right click on the appropriate code signing certificate and select “All Tasks” -> “Export…”
4. Choose the option “Yes, export the private key” when prompted
5. Accept the default options on the “Export File Format” screen
6. Enter a password for the private key, which will need to be entered when importing the certificate
7. Save the certificate to an appropriate location

Importing the Certificate for Trusting

Local Machines

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “Computer account” and select the local machine when prompted)
3. Right click “Trusted Publishers” and select “All Tasks” -> “Import…”
4. Follow the wizard to import the exported certificate, and enter in the accompanying password that was used when the certificate was exported
5. If the certificate is no longer required to be imported by other machines, it is highly recommended that the exported file is deleted  

Group Policy

1. Open the appropriate group policy for editing
2. Expand “Computer Management” -> “Policies” -> “Windows Settings” -> “Security Settings” -> “Public Key Policies”
3. Right click on “Trusted Publishers” and select “Import…”
4. Follow the wizard to import the exported certificate, and enter in the accompanying password that was used when the certificate was exported
5. If the certificate is no longer required to be imported by other machines, it is highly recommended that the exported file is deleted

After promoting or demoting a domain controller, you might have difficulties with WSUS, namely the Windows Internal Database. This occurs because the Windows Internal Database (essentially based on the SQL 2005 database engine) has recorded the SID (security identifier) for the SQL groups it creates when the database was installed, and the domain controller operation has now rendered them invalid.

When you try re-installing WSUS, you get this error: –

"Failed to connect to SQL server

SERVER\MICROSOFT##SSEE

[DBNETLIB]ConnectionOpen (Connect()).]SQL Server does not exist or access

denied."

Additionally, Application event ID’s 17204 & 17207 and System event ID 7024 may also be logged.

Attempts to start the “Windows Internal Database (MICROSOFT##SSEE)” service also fail, as well as attempting to uninstall the Windows Internal Database from Add/Remove Programs.

In order to resolve this issue, you’ll need to follow these instructions: –

1. Open the Registry Editor
2. Expand HKLM\SOFTARE\Microsoft\Microsoft SQL Server\MSSQL.2005\Setup
3. Export all configuration of this key in case a restore is required
4. Remove the “SQLGroup” and “FTSGroup” values
5. Uninstall the Windows Internal Database from Add/Remove Programs
6. Restart the WSUS 3.0 installation

Seems that everyone is talking about McAfee today, after their software inadvertently identifies svchost.exe on Windows XP SP3 machines (only) as W32/Wecorl.a (McAfee knowledge base article KB68780 regarding the 5958 DAT update on April 21, 2010).

Workarounds have been posted both by McAfee and by the information technology community, however the following might help speed things up if you have a large line of machines to fix by hand: –

1. Download the EXTRA.DAT file from Mcafee here – https://kc.mcafee.com/resources/sites/MCAFEE/content/live/CORP_KNOWLEDGEBASE/68000/KB68780/en_US/EXTRA.zip
2. Copy the EXTRA.DAT file to a USB key
3. Create a batch file with the following content, and save it to the USB key: –

echo off
echo Copying extra.dat…
copy extra.dat “%programfiles%\Common Files\McAfee\Engine”
echo Copying svchost.exe…
copy “%systemroot%\System32\dllcache\svchost.exe” “%systemroot%\System32”
pause
echo Restarting machine…
shutdown -r -t 0

Running this batch file will copy the EXTRA.DAT file in to place, and restore the svchost.exe from the dllcache directory (if it was quarantined) and then automatically restart.

This may not work in all cases, but I have seen a fairly high success rate with machines that I have done this on.

Microsoft Data Protection Manager (DPM) 2007 and 2010 allow online backups of Hyper-V guests, providing the guests and the Hyper-V server meet the necessary requirements as follows: –

http://technet.microsoft.com/en-us/library/dd347840.aspx

http://technet.microsoft.com/en-us/library/dd637102.aspx

There is another condition that I’ve encountered that causes a Hyper-V guest to report as “Backup Using Saved State” rather than “Backup Using Child Partition Snapshot”, where disks are marked as read-only.

In order to correct this, use diskpart to select the applicable disk and run “attrib disk clear readonly”, and then check that the Hyper-V guest reports as “Backup Using Child Partition Snapshot”.

Recently I had to replace a hard drive in one of my servers running Microsoft Hyper-V 2008 R2 which contained the virtual machine configuration and VHD files. I used robocopy to copy the data from the server drive, to a temporary drive, then replaced the drive before copying the data on to it.

Unfortunately, I forgot to copy the ACL’s as well, which caused issues when trying to start the virtual machines again. I use System Center Virtual Machine Manager, so when I tried to start my virtual machines again, I got the following error logged in the Jobs log: –

Error (12700)
VMM cannot complete the Hyper-V operation on the server.domain server because of the error: ‘Unnamed VM’ could not initialize. (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)

‘Unnamed VM’ could not read or update the virtual machine configuration because access was denied: General access denied error (0x80070005). Check the security settings on the folder in which the virtual machine is stored. (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)
 (Unknown error (0x8001))

Recommended Action
Resolve the issue in Hyper-V and then try the operation again.

In Hyper-V Manager, the following error is displayed when trying to start the same machine: –

‘SERVER’ failed to start.

Microsoft Emulated IDE Controller (Instance ID {598AFA1B-1726-44B7-8435-E00B2ACAF2B5}): Failed to Power on with Error ‘General access denied error’

IDE/ATAPI Account does not have sufficient privilege to open attachment ‘D:\Virtual Server\Virtual Machines\server\system.vhd’. Error: ‘General access denied error’

 Account does not have sufficient privilege to open attachment ‘D:\Virtual Server\Virtual Machines\server\system.vhd’. Error: ‘General access denied error’

[Expanded Information]
‘SERVER’ failed to start. (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)

‘SERVER’ Microsoft Emulated IDE Controller (Instance ID {598AFA1B-1726-44B7-8435-E00B2ACAF2B5}): Failed to Power on with Error ‘General access denied error’ (0x80070005). (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)

‘SERVER’: IDE/ATAPI Account does not have sufficient privilege to open attachment ‘D:\Virtual Server\Virtual Machines\server\system.vhd’. Error: ‘General access denied error’ (0x80070005). (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)

‘SERVER’:  Account does not have sufficient privilege to open attachment ‘D:\Virtual Server\Virtual Machines\server\system.vhd’. Error: ‘General access denied error’ (0x80070005). (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)

The issue is of course, that because the ACL’s weren’t preserved, Hyper-V can’t read the virtual machine files. Unfortunately, it’s not as simple as just adding the SYSTEM account to the root and applying permissions down, as Hyper-V R2 has it’s own security “namespace” (referred to in Microsoft documentation as the Service SID) called “NT VIRTUAL MACHINE” which contains the GUID’s for all registered virtual machines.

The easiest way to add permissions back to your virtual machines, in order to have them accessible via Hyper-V, is to use the following process on each machine (this is assuming you’re using System Center Virtual Machine Manager): –

• Open the directory that stores your virtual machine
• Open the “Virtual Machines” subdirectory under your virtual machine directory
• Record the GUID as per the file name of the .xml file in this directory
• Run icacls “<virtualmachinefolder>” /grant “NT VIRTUAL MACHINE\<virtualmachineguid>”:F /T (for example icacls “D:\Virtual Server\Virtual Machines\Server” /grant “NT VIRTUAL MACHINE\598AFA1B-1726-44B7-8435-E00B2ACAF2B5”:F /T

Now you should be able to start your virtual machine.

I came across a problem when I was installing SCCM 2007 on my Windows 2008 R2 server, where my Management Point was reporting this critical error: –

SMS Site Component Manager faild to install component SMS_MP_CONTROL_MANAGER on server myserver.

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.

Fair enough. I loaded the IIS management console, connected to the local server and opened the “WebDAV Authoring Rules” option. Here, I added a new authoring rule as the error message suggested, and altered the WebDAV settings to specify the advanced properties.

I had made another change that required a restart, so I restarted my server at this stage intending to re-test the management point when it restarted, however the error persisted. I re-checked the authoring rules and properties, and confirmed that they were correct, yet SCCM was still reporting this critical error.

I tracked down the configuration file for WebDAV under “C:\Windows\System32\inetsrv\config\schema\WebDAV_schema.xml” and compared this to the properties I had set via the IIS management console – They didn’t match!

The following section doesn’t line up with what I specified via the IIS management console: –

<attribute name=”allowAnonymousPropfind” type=”bool” defaultValue=”false” />
<attribute name=”allowInfinitePropfindDepth” type=”bool” defaultValue=”false” />
<attribute name=”allowCustomProperties” type=”bool” defaultValue=”true” />

These values should be “true”, “true”, “false”.

I wasn’t able to make any changes to this file without first taking ownership, due to the default ACL’s, but after I did that, I modified the values and re-saved the file (and also reverted the permissions back to the default).

After a restart of the “World Wide Web Publishing Service” and the “SMS_SITE_COMPONENT_MANAGER” service, everything started working correctly.

Recently I had to uninstall and re-install SQL 2005 Reporting Services for SCOM 2007 R2.

While configuring it using the Reporting Services Configuration Manager, under the Database Setup tab I was prompted to upgrade the database version. When I clicked OK, I got the following messages: –

The database version (C.0.8.40) does not match your Reporting Services installation. You must upgrade your Reporting Services database.

And then: –

Couldn’t generate the upgrade script. There is no upgrade script available for this database version.

Which had further details: –

ReportServicesConfigUI.WMIProvider.WMIProviderException: The version does not match a supported version.

Additionally, trying to access the reporting page via my browser gave me this error: –

The version of the report server database is either in a format that is not valid, or it cannot be read. The found version is ‘Unknown’. The expected version is ‘C.0.8.40’. To continue, update the version of the report server database and verify access rights. (rsInvalidReportServerDatabase)

The upgrade was failing because of a version mismatch, and this was caused by the Reporting Services component being installed individually from the SQL core services. The solution was to apply the latest service pack (SP3) to the SQL installation, which re-aligned the versions and allowed the ReportServer database to be upgraded via the Reporting Services Configuration Manager.