Clearing padlocks on SMS or ConfigMgr objects

During an in place migration from SMS 2003 to ConfigMgr a best practice is to build a new SMS site and attach it as a child so that you can replicate all of your objects, break the parent – child relationship and then upgrade to ConfigMgr. At that point you can decide if everything upgraded successfully, the new site is healthy, all objects have been replicated and then you can migrate your clients to the new ConfigMgr site. For more details on this migration strategy check out Kim Oppalfens’ blog post on how to transition from SMS 2003 to ConfigMgr 2007.


When you have a parent – child relationship any collection that is being replicated from the parent site will be locked and can be identified by the little gold padlock icon under the collection node. Now once that relationship is broken the objects that were being replicated will remain and the padlock should then disappear allowing you change that object’s properties. Once in while some of the padlocks will remain after the relationship is broken leaving the object locked and you unable to do anything with that object.

Sometimes the only way to unlock these objects is run a couple of commands in against your SQL database as outlined in Ed Aldrich's article on myITforum.com.

• Stop the SMS_Executive service
• Stop the SMS_Site_Component_Manager service
• Stop the Windows Management Instrumentation service
• Open Microsoft SQL Server Management Studio and connect to your site database
• Identify the collection ID that still has the padlock icon
• Right-click the database and select New Query
• Type select * from collections and click Execute (Red exclamation point on the SQL Editor toolbar)
• Type update collections set flags='18' where siteID='your collection ID' (Note all collection flags should be either 17 or 18)
• Restart your WMI, SMS_Executive and SMS_Site_Component services
• Open your SMS or ConfigMgr console and the padlock icon should be gone from the collection in question

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