The ability to inventory mapped network drives was a common customer ask in ConfigMgr 2007 and SCCM Expert and some other folks provided free scripts and MOF edits to take care of this.  But can this be done in ConfigMgr 2012? 

Mapped network drives and printers are a per-user setting so you need to run a script or process under the user’s context to grab that data and store it somewhere that the hardware inventory process can get to.  The obvious place to store the data is WMI.  There may be other scripts out there that do this and if you have a better way to do this in ConfigMgr 2012 please let me know, but I chose to use a script provided by CTS for ConfigMgr 2007 and it worked just fine in my lab.  Credit to Alvin Morales and JC Hornbeck for the blog article:

http://blogs.technet.com/b/configurationmgr/archive/2008/12/18/configmgr-2007-how-to-inventory-mapped-drives.aspx

Obviously in ConfigMgr 2012 we won't perform the MOF edits shown in the article, we make the change in the ConfigMgr 2012 console itself.  But the VB script provided (mapdrives.vbs is what they called it) is required.  Given the requirements that need to be met for this to work as a ConfigMgr package (run with user rights, run only when a user is logged on, set it to re-run on a schedule, etc) this may work better as a logon script.  You could also modify the VB script to inventory mapped printers as well.  You could further modify the script to force a hardware inventory once it’s done, or just wait for the next scheduled inventory to occur.

Once you have created the package and deployed it to your clients, you can verify it worked by using WBEMTEST to connect to root\CIMV2 and look in CX_mappeddrives.

In the ConfigMgr 2012 console you’ll need to add the new class for hardware inventory.  So, Administration/Client Settings/Default Client Settings (or select a custom device settings group)/Hardware Inventory/Set Classes.  Click Add and use the Connect option to specify a client that now has the information stored in WMI and select the CX_mappeddrives class name.

Once the client has retrieved machine policy and submitted hardware inventory, you should be able to see the mapped drive data in Resource Explorer:

and you can confirm in the database:

October 18!  http://blogs.technet.com/b/in_the_cloud/archive/2013/08/14/mark-your-calendars-for-oct-18-the-r2-wave-is-coming.aspx   Now you can get your upgrades and migrations done before the holiday season, not during!

There were issues reported for this update with ConfigMgr 2007 and 2012 when this update was original released.  An update was released this week

http://support.microsoft.com/kb/2872041/en-us

If you start testing the integration of Intune with Configuration Manager 2012 you’ll likely spend time waiting for the Dirsync process to run.  It runs every 3 hours by default which is OK for a production environment but when testing you want things to happen quickly so you can continue testing.  Here is a process you can use to manually kick off that dir sync process in your test lab.  This allows you to make changes in your AD (like creating new test accounts, password resets, etc) and get those changes communicated to the cloud.  I’m not recommending that you could or should use this in production as I don’t know if there are any support issues with doing this.  There also may be other ways to accomplish this but I figured this out in my testing and it works for me.  Your mileage may vary.

Once you have installed and configured dirsync look in \Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell and run miisclient.exe. 

This is the Forefront Identify Manager (FIM) client and we can use it to monitor and troubleshoot the dirsync process.  In the app we can monitor the status of the different sync jobs.  Look closely and you’ll notice a trend.  About every 3 hours (usually it’s 3 hours plus a few minutes) you’ll see 3 jobs run, in this order:  Delta Import Data Sync, Delta Confirming Import and Export.  I won’t go into the details about what those do now, will possibly cover it a later entry. 

If you select one of the Delta Import Data Sync records and right click, you’ll see a few options, with one being Run.  If you select Run and then verify the Run Management Agent options (basically in this example make sure the Management Agent is Source AD and that the Run Profiles options is set to Delta Import Delta Sync) and click OK the Synchronization Service Manager will create a new Delta Import Data Sync record with the current date/time stamp and set the status when it’s done to success (or failure if it fails).  Repeat the same process for Delta Confirming Import and then when it’s done run the Export.  Done!

If you want to confirm that the changes in AD are being picked up you can select the Delta Import Delta Sync record for the sync after the AD change was made and check the Synchronization Statistics window at the bottom and you should see some values in the Staging section.  In this example, the Last Name for my Intune test user account in AD was changed and I was expecting to see an update to that AD account get picked up and sent to Azure AD.   I used the Sync Statistics to verify that the change was processed and I was then able to go to my Azure domain and saw that the change was reflected there. Success!

Don't know that we have a formal announcement on an MS site yet, but there is some info on the possible issues here: http://myitforum.com/myitforumwp/2013/07/15/configmgr-issues-with-ms13-052-kb2840628/. This affects CM2007 and CM2012.

If you have issues with KB2840628 open a case with Premier Support.  And this just reinforces something I preach to my customers all the time:  You need a separate test lab that mirrors your production environment and you need to test everything in there (updates, images, packages, etc).  And testing in production is not testing :-)

7/17/2013: Updating entry with official word from product team: http://blogs.technet.com/b/configmgrteam/archive/2013/07/17/issues-reported-with-ms13-052-kb2840628-and-configmgr.aspx