Category: Windows

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.

I recently replaced one of my Hyper-V hosts with Windows Server 2008 R2, and noticed that I was getting the following event logged every two minutes: –

Log Name:      Microsoft-Windows-Hyper-V-VMMS-Admin
Source:        Microsoft-Windows-Hyper-V-VMMS
Date:          20/09/2009 5:52:42 PM
Event ID:      14050
Task Category: None
Level:         Error
Keywords:    �
User:          SYSTEM
Computer:      HyperV01.mydomain.internal
Description:
Failed to register service principal name.

 I was nearly certain that this was due to the fact that I hadn’t removed the computer from the domain before rebuilding it, and therefore it had acquired the old computer account when it was re-joined. This error indicates that there was an error updating the “servicePrincipalName” attribute of the computer account for my Hyper-V server.

I jumped in to my Active Directory to check out the permissions of the computer account first, and the first thing I noticed was that there was an unresolvable SID in my ACL. This wasn’t causing the issue, but it was a good indication that the permissions were probably in need of attention.

To understand how to resolve this issue, it’s important to understand what’s failing. In this case, we can see from the event 14050, that the SYSTEM account on my Hyper-V host tried to update the servicePrincipalAttribute of it’s own computer account within Active Directory, but failed. We believe it’s a permissions issue, so we should check the “SELF” entry in the ACL to see if it has the correct permissions: –

…And bingo! The “SELF” entry is missing the “Validated write to service principal name” permissions, so therefore it can’t write the attribute. “SELF” in this case, corresponds to the SYSTEM account of the host that owns the computer account.

So I went ahead and granted this permission to the computer account, and confirmed that the servicePrincipalName attribute updated on next attempt and that the events were no longer being logged.

Earlier in the year, I had a hardware issue which brought down one of my Hyper-V servers (and my virtual web server hosting this website along with it). When I finally resolved the issue (I had a faulty hard disk), I had to re-install Windows Server 2008 on the Hyper-V server and then bring all of my virtual machines back online. I wrote down my resolution steps, and now have finally had some time to share this.

I used Virtual Machine Manager 2008 to add the rebuilt server back in as a library server, and then copied my virtual machine files in to the Virtual Library share so that it would pick up the machines.

Each of my virtual hosts have two disks – One for the operating system, and one for the data. This meant that after I had finished creating the “new” VM using the .vhd containing the OS for each machine, I had to go back and attach the data .vhd as well.

It seems that when you do this (for whatever reason) the disk is not brought back online automatically. As I have my Active Directory database stored on my data drive, when the domain controller attempts to access the database, it can’t so it blue screens and then restarts. I don’t believe that this is the behaviour on Windows Server 2003 machines, so I am assuming it’s either the behaviour for Windows Server 2008 or maybe it’s just the Server Core install of Windows Server 2008.

In a nutshell, playing around with the virtual disks for a Windows Server 2008 domain controller can cause a lot of grief. If you ever get a BSoD with this message – “STOP: c00002e2 Directory Services could not start because of the following error: A device attached to the system is not functioning. Error Status: 0xc0000001. Please shutdown this system and reboot into Directory Services Restore Mode, check the event log for more detailed information.” – this just might be the reason.

EDIT (04/04/10): I have revisited this article as I ran in to another situation when moving a virtual machine recently. As F.H.R. stated in the comments below, Windows puts the secondary disk offline. If you bring the disk back online using diskpart or Disk Management, you might still have the same issues.

If you do still have a blue screen after bringing the disk back online, ensure that the disk is initialised. If you are using diskpart, select the disk and then use the command “attrib disk clear readonly” which should bring your domain controller back to life.

If you still have issues, follow the rest of this article.

In order to resolve this issue, I presented a new VHD to the domain controller and booted in to Directory Services Restore Mode. Once I was in there, I was able to move my Active Directory database across to this new disk, swap the drive letters around, and then restart.

I’m not sure why this is necessary, but I can tell you that 7 months later I have used this process a few times when playing around with my domain controllers, and with 100% success.