System Management

Yesterday I started to play with Hyper-V and SCVMM 2008. I added two hosts and also imported one virtual hard disk (with Windows Server 2003 SP2) to see if a .vhd created by Virtual Server 2005 SP1 works well in Hyper-V.

I noticed that I do not have an internet connection, actually there wasn’t any network adapters installed although I’m sure I had one. I installed Integration Services and it installed Microsoft Virtual Machine Bus Network Adapter. Ok, good. Looks like it doesn’t have the IP address set up. When I tried to configure the adapter, the following error occurred: “The IP address <ip address> you have entered for this network adapter is already assigned to another adapter…”

As I did not have any network adapter prior to installing Integration Services, I opened Device Manager and checked Show hidden devices from the View menu. The result: no Intel 21140-Based… adapter there. Nothing wrong here, this is by design. Installed devices that are not connected to the computer (i.e. USB device) are not displayed in Device Manager, even with Show hidden devices enabled.

So, in order to uninstall the old network adapter (Intel 21140-Based… in my case) do the following:

1. Click Start, point to All Programs, point to Accessories, and then click Command Prompt.
2. At a command prompt, type the following command , and then press ENTER:
   • set devmgr_show_nonpresent_devices=1
3. Type the following command a command prompt, and then press ENTER:
   • start devmgmt.msc
4. Troubleshoot the devices and drivers in Device Manager.NOTE: Click Show hidden devices on the View menu in Device Manager before you can see devices that are not connected to the computer.
5. When you finish troubleshooting, close Device Manager.
6. Type exit at the command prompt.Note that when you close the command prompt window, Window clears the devmgr_show_nonpresent_devices=1 variable that you set in step 2 and prevents ghosted devices from being displayed when you click Show hidden devices.

There is a KB article about this. Although the article applies to Windows XP only, the solution worked very well on Windows Server 2003.

Suppose you have created a task sequence, advertised it and booted from task sequence media or however you want; if you receive the following error: “Task Sequence: <TS name> has failed with the error code (0×80004005). For more information, please contact your system administrator or helpdesk operator.” at Setup Windows and ConfigMgr step you might want to check the Product Key! Most probably the key is not correct, so either write another one or remove the product key at all from Apply Windows Settings step in your task sequence and you will have to provide it during the install phase.

I left the product key blank and next time I booted the PC from the TS media, at the Setup Windows and ConfigMgr step I was asked to provide a product key. I entered my Business edition product key and everything was ok.

Few months  ago I had an interesting problem at a client site that took me a while to resolve. So I want to post it here, maybe it will help others…

After a successful upgrade from SMS 2003 to SCCM 2007 SP1, I configured software update point, synchronized with Microsoft update to get the list of updates for products I needed and created a new list with updates required by clients. When I tried to deploy software updates it should download the updates to my SCCM server. Well, this step failed. PatchDownloader.log reported the following:
Trying to connect to the root\SMS namespace on the XYZ-SCCM machine
Connected to \\XYZ-SCCM\root\SMS
Trying to connect to the \\XYZ-SCCM\root\sms\site_XYZ namespace on the machine
Connected to \\XYZ-SCCM\root\sms\site_XYZ
Download destination = \\XYZ-SCCM\WsusContent\08123a3c-c7fd-43a4-a4ce-80089b1267df.1\WindowsXP-KB938828-x86-ENU.exe
Contentsource = http://www.download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/windowsxp-kb938828-x86-enu_ba3f0cbe4ba5736d4254732e41fe058697b76ebc.exe
Downloading content for ContentID = 8170, FileName = WindowsXP-KB938828-x86-ENU.exe
Try username DOMAIN\USERNAME from the registry
Proxy enabled proxy server ISAserver:8080
HttpSendRequest failed 12007
Download http://www.download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/windowsxp-kb938828-x86-enu_ba3f0cbe4ba5736d4254732e41fe058697b76ebc.exe to C:\DOCUME~1\ADMINI~1.LAB\LOCALS~1\Temp\2\CAB3B.tmp returns 12007
ERROR: DownloadContentFiles() failed with hr=0x80072ee7


First I thought it was a stupid error, as I set (and checked twice) all correct information. Looks like proxy information was old and not updating with what I have set later in SCCM. So I needed to remove old information and set the new ones again.

I have checked the registry and I couldn’t do much as username and password was encrypted. Well, I used upddwnldcfg.exe (from <ConfigMgrInstallationFolder>\bin\i386\00000409 folder on a x86 machine) to delete all proxy information stored in the registry and added the new username, password and server’s IP address. After this, downloading updates worked perfectly. More information about configuring proxy settings using upddwnldcfg.exe, you can find here: http://technet.microsoft.com/en-us/library/bb892795.aspx

A few days ago I had to make an image with Windows XP SP3 with all needed applications for lite touch installation.

Everything went well and I was happy until I entered the mini-setup phase on the first computer with that image applied on it. I received an error regarding the product key. I guess I tried a dozen of product keys but none of them worked. After reading the message again and more careful, I realized that the problem was with my Windows XP media – it was not a VL media. And I realized this because the message said to look for a product key on the Certificate of Authenticity (COA) sticker and not my License Agreement…

Resolution

Got another media with Windows XP SP3 VL and made a repair. During the repair phase, I provided the VL product key and it worked. Next time I entered the mini-setup, I filled in some info and that was it.

I just spent half an hour trying to understand why my task sequence cannot find the files on a distribution point; although the TS runs normally, I see all available TSs and I can choose the one I need. Then I found why: I missed something I never missed before and that must not be forgotten! I forgot to configure the network access account .

So, if you receive the following error: “This task sequence cannot be run because the program files for <your package here> are inaccessible on the distribution point.”

you should check if your network access account are configured and the information is correct.

To resolve this issue, you must correctly configure the System Center Configuration Manager 2007 client network access account. To do this, follow these steps:

1. Use an account that has administrative permissions to log on to a computer that has the System Center Configuration Manager 2007 Administrator Console installed.
2. Click Start, click All Programs, click Systems Management Server, and then click SMS Administrator Console.
3. Expand ServerName, expand Site Management, expand SiteName, and then expand Site Settings.
4. Click Client Agents, right-click Computer Client Agent, and then click Properties.
5. In the Computer Client Agent Properties dialog box, next to the network access account that you want to configure, click Set.
6. In the Windows User Account dialog box, enter the user name and the password that you want to use for the network access account, and then click OK two times.

Here is Microsoft’s article about this: http://support.microsoft.com/kb/935914

Do you know how Microsoft IT manages thousands of servers worldwide in multiple countries for a large number of departments and customers using SCCM 2007?
If no, then you should listen to this 30 minutes podcast: Microsoft IT Business Case for System Center Configuration Manager 2007 in a Data Center.

And here is the full article about this business case. I found it very interesting…

My last post (Using Group Policy to deploy Office 2007) was quoted on TechEdBloggers site.

Last week I tested how Office 2007 installs via Group Policy.

I created a software installation package and it worked successful; except the fact that it is not fully installed when a user logs on and that it will not upgrade (or remove) the existing version of Office even if I added the Office 2003 package that should be upgraded. After the Office 2007 installs, the users will have both version of Office – 2007 and 2003.

This is because Microsoft changed a little the way Office 2007 installs; and here they explain why they did this. Bellow are some considerations from that article:

• Difficulties with scheduling installation, consistently managing network bandwidth, and providing feedback on the status of the installation.
• Limited ability to customize features or user settings before installation of the 2007 Office system. You cannot use Office Customization Tool to create an .msp file. All customizations have to be made in the Config.xml file.

So, the best way to install Office 2007 in a medium organization is to use System Center Essentials or Configuration Manager in a large organization. Using these tools you can know exactly what features to install, when to install and how to install or upgrade Office 2007 suite.

Something I have learned the other day…

I had to install a small .msi using Group Policy, using a logon script. As it was a small package and not very important, I used a User Configuration Logon script.

I created and linked a new GPO to a specific OU with some users (with no admin privileges) and client computers only. The script run well and the package installed very quickly on all machines in that OU.

The problem was that I have another OU with member servers and at the moment I logged on to one server using a normal user account, I had the package installed right after first logon. This is because I configured User Configuration logon script instead of Computer Configuration startup script.

What I’ve learned? That I should plan more careful even the installation of a small package.

In case you have PXE Boot working normally but suddenly it is not working anymore, it may be because of the WDS service. This might sound strange but sometimes Windows Deployment Services (WDS) Server does not start after restarting the server, even if it is set to automatically start. It happened to me a few times….

Starting the service fixed the problem (in my case) every time. I didn’t tried, but maybe configuring delayed start for this service will fix the problem in the future.