Problems accessing file shares from Server 2008 R2 using the SMB protocol

My current ConfigMgr infrastructure includes distribution points scattered around North America and Caribbean. We are forced to use a simple file share as these devices don’t support IIS so packages are replicated using the SMB protocol. These remote devices were first used for our SMS environment where my primary site server was running Windows Server 2003 and I had very few problems. Since I have moved to ConfigMgr, where my primary site server is running Windows Server 2008 R2, I have had nothing but grief. Most of the time my site will fail to establish a connection to my remote devices until I reboot the server. The reboot is a temporary fix as the connection problem will resurface shortly. I’m able to connect to the share from other machines and my connection account is a local admin on the distribution points. I can ping the remote device from the site server but when I browse to the share I get the following error:

Error code: 0x80070035
The network path was not found.

After a little digging I came across Microsoft article KB2194664 referencing these exact symptoms. Essentially the Mrxsmb10.sys driver specifies a logon ID the first time that a connection is established to a remote share using the SMB protocol. The logon ID and the name of the server are saved in a server entry of the SMB Redirector. However, the Mrxsmb10.sys driver does not update the logon ID after the initial logon. Any attempt thereafter to use the name from the first connection will fail regardless of the user name. The hotfix referenced on the KB article will resolve this issue and has helped immensely in my environment.

MP needs to reload the hardware inventory class mapping table warnings

Recently during a ConfigMgr upgrade my SMS_MP_CONTROL_MANAGER was littered with the following warnings:

MP needs to reload the hardware inventory class mapping table when processing Hardware inventory. The MP hardware inventory manager cannot find a WMI class definition in the mapping table when processing a report. This should only happen if new definitions beyond those known to the SMS are added to the collected classes.


Possible cause: Inconsistent way the new definitions have been introduced.


Solution: Check that the mapping tables contain the information consistent with the hardware definition tables and that the definitions have been propagated properly.


Possible cause: Corruption of the data base.
Solution: Check the consistency of the data base.

After a little research I found that this is usually caused by clients that have a version of SMS.Def.mof that is out of sync from the version found on the site server. These messages should only happen once per client as they pull down and update the version of their SMS.Def.mof file. In my case I was upgrading from SMS 2003 to ConfigMgr and as more and more clients updated their SMS_Def.mof file these messages started to reside. If you continue to get these messages it would be a good idea to engage Microsoft CSS.

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