Server 2008 R2 and wmiprvse.exe crashes

Recently I was checking the health of a couple of my primary site servers and as I was going through some of the logs I noticed in the application event log there where event 1000 application errors that kept reoccurring. It seemed that every couple of days wmiprvse.exe would crash and then restart but with little noticeable effect. After some digging I came across a blog entry describing a problem with SCVMM and WMI. It referenced a wmi hotfix (KB981314) that Microsoft released that deals specifically with event 1000 wmiprvse.exe errors. I decided to install the hotfix on the two site servers experiencing the problem as they are in a staging environment. Since installing the hotfix on both servers the number of wmiprvse.exe crashes has dropped significantly. It’s only been about three weeks but things are looking good…

Config Mgr Client Health Monitoring

One of the most important things in any ConfigMgr environment is the health of your clients. If your machines aren’t reporting in properly you’re dead in the water until you get the issue resolved. Since the ConfigMgr client is such a heavy hitter on WMI problems are not uncommon. For those who can’t afford a solution such as 1E’s WakeUp (which has client health monitoring built in) using a start-up or shutdown script is an inexpensive way of monitoring ConfigMgr client health. There are many scripts published out there but one of the best that I have come across is Chris Stauffer’s SCCM SP2 Health Check Startup Script found at myITForum.com. This script also works nicely during a SMS 2003 to ConfigMgr migration to ensure that all of your machines get upgraded properly. It's easy to configure and with the help of Active Directory can be deployed within minutes.

SharePoint Install for ConfigMgr Dashboard

When I was setting up my Config Mgr dashboard I ran into a few gotchas. First, we don’t use the default port for SQL and our DBA team keeps a close eye database name length and relevance. No problem right? With most application installs you can specify your SQL connection settings and database name. Well this is almost true when installing Windows SharePoint Services. During the initial SharePoint install you are prompted for the SQL server and database name which is fine except if you need to specify a non-standard port. The SharePoint installer prerequisite check allows you to specify non-standard port in the following format:
servername, port

However once you get past this step the installer will fail with an error about an invalid loopback address and then it references your server name and the port. A quick way around this is to create an ODBC data source for your SQL server on the SharePoint server:

• Open the Data Sources (ODBC) Administrator console (Administrative Tools)
• Create a new SQL System DSN
• Specify a name, description and your SQL server (Do not specify a port)
• In Client Configuration uncheck Dynamically determine port
• Enter your SQL port in the space provided
• Test your connection (Note you need to be logged in with an account the has the appropriate permission on the SQL server)

Note: If you are running a 64-bit operating system such as Server 2008 R2 then you will also need to launch the 32-bit version of odbcad32.exe (Found at C:\Windows\SysWOW64) and create your DSN there as well. The 64-bit install for the ConfigMgr dashboard will look at the ODBC connections listed at HKLM\Software\Wow6432Node\ODBC\ODBC.INI during the install and will fail if your connection settings aren't listed.

Now when you run the SharePoint installer you don’t have to specify the port for SQL which will allow setup to complete successfully. The next problem that I ran into is once SharePoint is installed it creates an additional database called SharePoint_AdminContent_GUID. With this naming convention it made it difficult for our DBA team to manage and support it. Think about if you have multiple SharePoint farms that you have to manage the databases for and they all have databases called SharePoint_AdminContent_GUID it could get confusing pretty quick. We decided to change the name of this database to something a little more descriptive. Due to the fact that this is the database Central Administration web application there are few extra steps that you must complete.

• Have a DBA backup the database and restore it with a more appropriate name
• From your SharePoint server open the SharePoint Central Administration console and navigate to Application Management \ Content Databases and find the one you are looking for. In this case it’s the Central Administration web app.
• Select the database and then check “Remove content database” (Located at the bottom of the page once you have opened up the content database)
• Since this is the content database for the Central Administration site you can no longer use the GUI to manage the settings
• Open up a command prompt, change the directory to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN and then run the following command

stsadm -o addcontentdb -url http://servername:port number -databasename database name -databaseserver database server name

At this point you should be able to go back into the GUI and manage your SharePoint farm.

ConfigMgr OSD App Tree

There are many ways of deploying applications during a task sequence but I wanted to give my deployment guys the ability to assign applications on the fly and from within the task sequence. This is especially handy for bare metal deployments. Thanks to Jason Sandys and his OSD App Tree utility this can be done very easily. The OSD App Tree is a small utility that provides user interaction during the task sequence by referencing an XML file to assign applications. You have the ability to set up application groups, organize them in a tree view, make them optional or mandatory, use conditions, etc. Check it out here…

http://myitforum.com/cs2/blogs/jsandys/pages/osdapptree.aspx

Setting Broadcom NICs to 100/FULL during an OSD Task Sequence

In our environment we require all our workstation NICs to be set to 100/FULL. Currently this is a manual step at the time of deployment and from time to time it can be missed. As I was migrating all of our images to Config Manager my goal was to automate as much as possible - such as NIC speed and duplex. Hard coding a NIC for a Windows PE boot image is pretty straight forward – extract the driver, open up the INF file, locate the section were the default speed is listed, set it to whatever value you require and then inject the driver into your boot image. However if you use the same approach when installing drivers during an OS deployment task sequence and you are using a Broadcom NIC your NIC driver will fail to load correctly causing the task sequence to error out. Once you edit the INF file you break WHQL driver signing therefore Windows XP will not install the driver. A quick way around this is to leave the INF file untouched and set it 100/FULL by calling the following script during your task sequence.

Dim WSHShell, RegLocate, RegLocate1
Set WSHShell = WScript.CreateObject("WScript.Shell")
On Error Resume Next

'Locate registry setting for media type
RegLocate = "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\0001\RequestedMediaType"

'Change media type to 100/Full Duplex
WSHShell.RegWrite RegLocate,"6","REG_SZ"

'Exit
WScript.Quit 

1. Create a package in Config Mgr containing your script - no program necessary
2. In your task sequence add a command line step after your driver installs
3. Name this step something like "Set Broadcom NIC to 100/FULL" (helps for future reference) 
4. Add the following command line - cscript.exe script name.vbs
5. Enable the package check box and browse for the package containing your script

Add a condition to this step and enter the following WMI query to ensure that your script only runs on Broadcom based NICs.

SELECT * FROM Win32_NetworkAdapter WHERE Manufacturer LIKE 'Broadcom%'