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%'

Configuration Manager PXE Cache Behaviour

If you’ve spent any time dealing with Config Mgr OS deployments using PXE you’ve probably had machines fail to connect to PXE service point with errors such as “TFTP download failed” or “unable to connect to PXE server “. Believe it or not this is by design – especially if you are using unknown computer support. This is most likely due to a previous task sequence being advertised to that machine. By default Config Mgr will cache the PXE advertisement for 60 minutes (Default setting) and then it will expire. Most of the time you can right click the collection the collection that the machine sits in and select “Clear last PXE advertisement” but sometimes you have to go as far as restarting the WDS services. Microsoft published a hotfix under KB969113 for Config Mgr SP1 that will reduce the interval from 60 minutes to 2 minutes and in SP2 the cache expiry can be set in the registry.


On an x86 machine the located under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\PXE

On an x64 machine the registry key is under:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\SMS\PXE

Create a new DWORD value CacheExpire and set the desired value in seconds. Be careful if you have R2 installed and unknown computer support enabled because if you set the cache expire value too low and you are using a mandatory task sequence your machine will continuously start the same task sequence every time it reboots. There is a good post on the System Center Configuration Team blog that details PXE cache expire behaviour - http://blogs.technet.com/b/configmgrteam/archive/2010/05/27/pxe-cache-expire-behavior-in-configuration-manager-2007-sp1-and-sp2.aspx

Configuration Manager v.Next Beta 1 Released

On Monday Microsoft released the beta of the next iteration of Configuration Manager… v.Next. With Config Mgr v.Next there is shift towards user centric client management. It will be like going from Windows XP to Windows 7 as this release is going to have the longest development cycle since SMS 2.0. Since moving to v.Next is such a big step the only migration plan available is a side by side upgrade. Config Mgr v.Next will be fully 64-bit and include a completely new application delivery engine, a new UI (good-bye MMC console) based on the SCOM code base, SQL Reporting Services will replace SMS / SCCM reporting, and much more importance will be placed on the DCM engine. I was able to test drive v.Next at MMS and I was really impressed with what I saw. The v.Next beta is public so download it from Microsoft’s Connect site and get it into a lab.