Andy Dawson's Blog

Building a Hyper-V virtual machine from scratch almost always seems to involve mounting an ISO image at some point during the installation process. I suspect that like us, many other organisations already have a network location in which we store ISO images. The ability to mount an ISO image from our usual network location saves us having to copy the ISO images to the local Hyper-V servers.

The ability to remote mount an ISO image requires that a couple of configuration changes are made. Attempting to remote mount an ISO image without making the configuration changes usually results in an err along the lines of

Inserting the disk failed

Failed to add device ‘Microsoft Virtual CD/DVD Disk’

The file ‘\\RemoteServer\Share\ISO_Image.iso’ does not have the required security settings. Error: ‘General access denied error’

There are two configuration changes that need to be made. The first is ensuring that the Hyper-V hosts can access the share itself that contains the ISO images. As a workaround, you can always grant ‘Everyone’ read access to the share. If you want to control access to individual servers, you need to specify the Active Directory computer object for each server you want to give access to.

The second configuration change that is required to to grant Constrained Delegation on the virtual host objects in Active Directory:

• Log onto a domain controller and open Active Directory Users and Computers from the Administrative Tools menu, or open the remote administration Active Directory tools from another server or client
• Locate the Hyper-V host computer object
• Right-click the object and Select Properties from the context menu
• Select the Delegation tab
• Select the ‘Trust this computer for delegation to specified services only’ radio button and then the ‘Use any authentication protocol’ radio button
• Click the ‘Add’ button:
  
• The ‘Add Services’ dialog will open:
  
• Click the ‘Users or Computers’ button and add the remote server hosting the ISO images. Click OK
• Select the ‘cifs’ service type from the list shown:
  
• Click OK to close the dialog, the computer object properties should look like the following:
  
• Click OK to apply the change
• Repeat the above steps for any other Hyper-V hosts servers.

You should now be able to remote mount ISO images from the server specified.

I recently saw the above error on a SharePoint 2007 install of a test system. Reading a few blog posts, it seemed that most people were reporting the error as an issue when there was a problem with communication between the SharePoint server on which the wizard was being run and the domain controller it was connecting to as its logon server.

My machines didn’t seem to have any issues talking to each other however. Just to make sure, I changed them both over to a private virtual network, but that didn’t seem to help at all.

After a bit more rummaging, it turned out that the batch file I had used to create the users I needed for the SharePoint service accounts on the domain controller hadn’t created the ‘user@domain’ format of the user account correctly.

Recreating the users manually immediately solved the problem and the wizard ran successfully.

The above two errors hit me recently while I was trying to get a CRM 4.0 development environment installed for some upcoming work.

The first error shows up when the CRM 4.0 installer is checking the server configuration of the computer on which it is being installed as one of the final steps before installation commences. I checked that .NET 2.0 was installed and patched (it was) and that I had run the correct aspnet_regiis command to install ASP.NET 2.0 and update the scriptmaps (I had). As I’d patched the server completely, the server now had .NET 4 installed and following a bit if research, it appears that for CRM 4.0 installation, this interferes with the detection of ASP.NET 2.0. There’s a good walkthrough of the workaround, which involves adding a new ISAPI filter at the root of the websites listed in IIS manager, at http://www.powerobjects.com/blog/2010/08/14/ms-dynamics-crm-installation-asp-net-2-0-is-not-installed/

For the record, in this instance I was using Windows Server 2003 R2 x86 for the CRM server and Windows Server 2003 R2 x64 for the SQL server.

Following the above error, I also saw an issue at the very end of the installation, whereby the CRM Asynchronous Service failed to start. The error shown in the dialogue was

“Action Microsoft.Crm.Setup.Common.RegisterAsyncServiceAction failed. An exception occurred during the Commit phase of the installation. This exception will be ignored and installation will continue. However, the application might not function correctly after installation is complete. Time out has expired and the operation has not been completed.”

In addition, the following was recorded in the crm40svrSetup.log file located at C:\Document and Settings\<user name>\Application Data\Microsoft\MSCRM\Logs

12:10:24|  Error| System.Exception: Action Microsoft.Crm.Setup.Common.RegisterAsyncServiceAction failed. ---> System.Configuration.Install.InstallException: An exception occurred during the Commit phase of the installation. This exception will be ignored and installation will continue. However, the application might not function correctly after installation is complete. ---> System.ServiceProcess.TimeoutException: Time out has expired and the operation has not been completed.
   at System.ServiceProcess.ServiceController.WaitForStatus(ServiceControllerStatus desiredStatus, TimeSpan timeout)
   at Microsoft.Crm.ExtendedServiceInstaller.StartService(Object sender, InstallEventArgs e)
   at System.Configuration.Install.InstallEventHandler.Invoke(Object sender, InstallEventArgs e)
   at System.Configuration.Install.Installer.OnCommitted(IDictionary savedState)
   at System.Configuration.Install.Installer.Commit(IDictionary savedState)
   --- End of inner exception stack trace ---
   at System.Configuration.Install.Installer.Commit(IDictionary savedState)
   at System.Configuration.Install.AssemblyInstaller.Commit(IDictionary savedState)
   at Microsoft.Crm.Setup.Common.RegisterAsyncServiceAction.Do(IDictionary parameters)
   at Microsoft.Crm.Setup.Common.Action.ExecuteAction(Action action, IDictionary parameters, Boolean undo)
   --- End of inner exception stack trace ---, Error, RetryCancel, Option1

I also noticed that on the SQL server, the following error was reported:

This indicated a possible issue with Kerberos and following a bit of investigation, this turned out to be the case. Microsoft have very helpfully supplied a walkthrough for correcting the issue at http://support.microsoft.com/kb/921393 (although personally I find using ADSIEdit far easier than SetSPN; ADSIEdit can be installed on Windows Server 2003 R2 from the \Support\Tools folder of the installation media).

Once the correct SPNs were in place, the CRM Asynchronous Service started successfully.

I recently saw some disk related errors on my Windows Home Server. Following the usual course of action, which is to check the disks using the folowing batch file:

net stop pdl
net stop whsbackup
chkdsk D: /x /r 
chkdsk C: /x /r
for /d %%1 in (C:\fs\*) do start chkdsk /x /r %%1

all seemed fine. Only minor disk problems were encountered (half a dozen unindexed files were indexed) on one disk.

Following a reboot at the end of the process however, I could not connect to the Home Server console. When I logged onto the server, I immediately saw a notice that one or more services had failed to start (never a good thing) and when I tried to start the console the message I received was

"The Windows Home ServerConsole cannot start because the Windows Home Server Storage Manager Service is not running. Please restart Windows Home Server. If the problem persists contact Product Support"

Following a reboot nothing had changed, I saw the same services related error and could not start the Home Server console.

I had a quick look at the services which had failed to start and could see quite a few Home Server related services which should have started, but hadn't. Working from the Windows Home Server Storage Manager service, I could see that of all of the dependencies, the only service which hadn't started was the Volume Shadow Copy service. This service was set to manual, but trying to start the service manually gave a 'the service did not respond in a timely fashion' error after only a second or so and I suspected that this was the root cause of the issue.

A search on the internet resulted in a few suggestions for patches to fix the issue. Trying KB826936 didn't help; the patch was rolled into one of the service packs that I already had installed. KB940349 however installed fine and following a reboot everything fired back into life!

To add domain users to a local machine group using Group Policy, we need to use the Restricted Groups feature.  For the example shown below, I’ll be using a Windows Server 2003 domain functional level.

1. Create a new global/universal security group in Active Directory to contain the users which you wish to add to the local group on the target machines.
2. Make the domain users you wish to add to the local group on the target machines members of this new group.
3. Open Group Policy Editor and navigate to the OU where the target machines reside.  For example, if we have a ‘Desktops’ OU which contains the machines to which we wish to add the domain users, that is the location of the group policy we need to edit or create.
4. If a Group Policy already exists for the OU selected, edit the Group Policy.  If there is no Group Policy for the OU selected, create a new group policy and then edit it.
5. Within the Group Policy, navigate to Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Restricted Groups
6. Right-click on either Restricted Groups in the left pane of the Group Policy Management Editor, or in the right pane, and select Add Group.
7. The ‘Add Group’ window appears:
   
8. Click the ‘Browse’ button to open the ‘Select Groups’ window and select the group created in step 1, above, then click OK.  Click OK on the Add group window.
9. The Properties window for the Restricted Group appears:
   
10. The Properties Window has two membership areas; ‘Members of this group’ and ‘This group is a member of’.  Adding users to the ‘Members of this group’ option would add domain users to the Active Directory group created in step 1, and would remove any members of that group already there. As we added the required users to the group created in step 2, we shouldn’t need to use this option. Adding group names to the ‘This group is a member of’ option adds the security group and its members to the group(s) specified.
11. Click Add next to the ‘This group is a member of’ option and enter the names of the local groups you wish to have the domain users added to (e.g. Administrators, Users, Performance Monitor Users etc.) and click OK.
12. To test that the above steps have worked, log onto one of the target machines, run ‘gpupdate’ from a command prompt and check the local groups specified above for the new members.

I’ve been a bit delayed writing this final blog post from Tech Ed EMEA 2008, so I’m back in the UK. The final day at Tech Ed 2008 EMEA IT was not quite as session filled as previous days, mainly because Rik and I had to be heading off to the airport shortly before 3pm to catch our flight home.

The first presentation of the day was on getting the most out of WSUS 3.0 SP1. One of the items that was mentioned was the arrival of WSUS 3.0 SP2; this is currently in the planning phase and aims to fix the top customer and partner issues seen. It will also install on Windows Server 2008 R2. A number of scenarios for WSUS were discussed, including larger numbers of clients, branch offices and disconnected clients (submarines being the example used!) and some best practices discussed. If the video of this talk is available (at the time of writing, it isn’t unfortunately) and you use WSUS, I’d recommend watching it.

The second (and last) talk of the day I went to discussed Exchange 2007 SP1 and Hyper-V. The good news is that Exchange 2007 SP1 is fully supported on any of the x64 hypervisors validated by Microsoft on Windows Server 2008. If you want to virtualise your Exchange 2003 installation, you’ll need to use Virtual Server 2005; note that Exchange 2003 is explicitly not supported on Hyper-V.

Following these talks Rik and I spent some time talking to more of the experts in the ask the experts pavilion and got some answers to some long-standing questions.

Our flight home was uneventful, but it seemed rather cold when we stepped out of the plane at Manchester after the week in Barcelona!

Today I had to run aspnet_regiis -ga domain\user to grant a specific domain user account access to the IIS metabase and other directories that are used by IIS.  The server in question is running Windows Server 2003 R2 x64 edition and after running aspnet_iisreg from the C:\Windows\Microsoft.NET\Framework\v2.0.50727 directory, I received an error that read:

'An error has occured: 0x000703f0 An attempt was made to reference a token that down not exist.'

After a quick look at the server, I noticed that the .NET 2.0 framework was actually the x64 version rather than the x86 (i.e. 32-bit) version that I had assumed.  Running the aspnet_regiis command from the C:\Windows\Microsoft.NET\Framework64\v2.0.50727 directory, the command completed successfully.