Michael Griswold's SCCM Tips and Tricks

SCCM, Intune, and you

Mike Griswold — Fri, 03 May 2013 13:44:00 GMT

With System Center 2012 Configuration Manager Service pack 1 came new ways to manage new OS types. Mac and Unix/Linux management were big additions, but perhaps equally big was the expansion of mobile device management to manage things like iOS devices, Android devices, Windows Phone 8, and Windows RT devices. This management is a richer management than we had for ActiveSync devices in SCCM 2012 RTM and different than what we have for older devices like WinCE and Windows mobile 6.x devices in SCCm 2007 and SCCM 2012 RTM. This new functionality is via a connection with Intune, Microsoft’s cloud solution for device management.

What is Intune?

Intune is a fully standalone solution for managing devices from the cloud. It is a subscription service you can use and it will manage full OS machines as well as mobile OS like those I mention above. Rather than duplicate efforts for mobile device management the SCCM 2012 product leverages Intune’s communications and functionalities to mange these devices, but moves the management responsibility back to the SCCM admin console so all management of devices can be done in one place.

How to hook SCCM and Intune together?

There are many settings and specifics to setting up Intune and configuring it to work with SCCM. Craig Morris from the SCCM product group put together a great blog post on the subject so I’m not going to try and duplicate that here, but rather give a few key pointers to be aware of.

The first step to hooking SCCM and Intune together is to have SCCM and Intune. You need to have SCCM 2012 SP1 as a minimum, and then you need to setup an Intune account. There is a 30 day free trial so clear your calendar for the next month and give it a shot to see if it is right for you. TIP 1 - When you set it up you probably don’t want to use any existing account you have to use for Hotmail, MSDN, SkyDrive, etc. Intune will be tied to your account so you probably want to setup or use some kind of generic account for your company rather than one tied to you personally. It makes it easier for you to retire down the road when that day comes.

TIP 2 - The next pointer is that once you setup Intune and you start poking around DO NOT set the Mobile Device Management Authority. This setting can be done once, and only once. If you do it wrong you have to “tear up” your Intune site, throw it away, and make another one. Let SCCM set it for you when you are ready.

The next part of integration is up to you what you want to do. In the ideal world you would setup Single Sign On (SSO) so your users can use their domain credentials. For me and my test lab I was limited by the lack of an internet resolvable domain name so I couldn’t do it and had to do some workarounds. If you do want to set it up you will need to look into setting up an Active Directory Federation Services (ADFS) to aid in the syncing. This leads to TIP 3 – Make sure the Universal Principal Name (UPN) of your domain user accounts can be resolved by the Microsoft AZURE cloud. Said in other terms, if your users have accounts like user@domain.internal and your company is externally reachable by user@company.com.., you are going to have some hurdles to jump over to get things working correctly. Once you have your UPN figured out, use DIRSYNC to get accounts into Intune and then activate them in Intune.

Once you have all that in place you get to head to the SCCM 2012 admin console to complete the last bits. You need to setup an Intune subscription to link things together, and you need to setup an Intune connector site system role (similar to a Distribution Point) so you can publish content for devices into the Intune cloud. In this process you should also create a user based collection as your control point of what users will be allowed to use devices managed via Intune. You might want to start with only a test user or two (who has the correct UPN) and eventually expand to all the users in your organization. TIP 4 - Keep the users in this collection set as activated users in Intune for best results.

Now what?

These will get you a link between Intune and SCCM, so now you are ready to manage some devices. I’ll be adding some future blog posts to talk about how to setup a connection with each type of mobile device and distribute software to it… so stay tuned.

KB2775511 deployment for the SCCM Admin

Mike Griswold — Wed, 13 Mar 2013 22:40:00 GMT

This week Microsoft rolled out a BIG hotfix (90 hotfixes) rollup for Windows 7 SP1 and Windows Server 2008 R2 SP1. To better understand all the goodness it gives you check out the AskPFEPlat blog or go to the source of one of the guys who helped put it together, my fellow PFE Jeff Stokes. It is being distributed as an enterprise hotfix and so I think it likely that a lot of you folks running SCCM to manage your enterprise might want to roll out this hotfix. One big advantage that comes to mind is including it in your OSD image capture to cut down on patch install time for future deployments. The trick is that “out of the box” you can’t deploy this. It does not sync to WSUS and your SCCM software update point (SUP) automatically. There are some simple steps you can take to get it there, however.

On your central site/CAS SUP open up the Windows Server Update Services admin console

It is worth noteing that we see SCCM folks do more harm than good in the WSUS admin console, but this is one of those exception times you need to go in there. Do so carefully.

Go to updates and select Import Updates to launch a webpage to the Microsoft Update Catalog.

Search on 2775511 and then add all that you are interested in getting for your environment

Make sure the checkbox to import directly is selected then hit the import button.

Another box will come up tracking the download and show success when completed

Verify that your SCCM site is set to sync "Updates" classification, becase that is what this is (as compared to "service packs" or "security updates").
Once that download is complete you can sync SCCM and then you should see the updates in SCCM to deploy as you would any other update

3-14-13 update - Added links to AskPFEPlat and Jeff Stokes' blogs along with warning about using WSUS admin console

3-14-13 update #2 - added clarity about fix classification

The best group is a DP group!

Mike Griswold — Fri, 08 Mar 2013 16:17:00 GMT

There are all kinds of new features in System Center 2012 Configuration Manager (SCCM 2012) and you have probably read about, watched video, or made use of many of them. As I visit customers I find there is one very cool feature that most folks don’t realize is actually there: Distribution Point groups

Distribution groups aren’t really a new feature per se. They existed in SCCM 2007. However, their usefulness in 2007 was limited. They were only useful as a UI convenience during package distribution UI. In SCCM 2012 they are much more than that. They are a very useful tool.

The great thing about DP groups is that you can target software deployments at the DP group and then content will be added dynamically to any DP which is added to that group. Because of this I recommend to all my customers that even if they only have 1 DP they should make a DP group, put the 1 DP in it, then target all software distributions to the group, not the named DP. I tell them this to make the future better and easier. Compare this future scenario with and with out a DP group:

Your SCCM 2012 site has been up and running for a year. You have 100 packages already deployed to your single remote DP but the hardware is old and failing so you want to rebuild it into a play toy for your new hire to train on. You finally got the funds for new hardware and built it out to be your new remote DP. Now you have to get your packages deployed to it.

Non-group option:

Go to a package and distribute the content to the new DP
Wait 5+ minutes and confirm the DP has received all the content
Go back to the package and delete the old DP so the package files will be removed from it
Repeat steps 1-3 99 more times for the entire day, maybe into tomorrow
Claim overtime if you are allowed to

DP group option:

Since you deployed all the content to the DP group you just add the new DP to the existing DP group as you head home for the day
Let all 100 packages replicate to the new DP over night, minimizing impact to your network when users need it
Come in the next morning navigate to Administration\Distribution Points, select your old DP and from the properties/content tab do a multi-select and delete all the packages from it.
Do the other work your boss expects from you..., SCCM is good to go.

How is that not cool?!?!?

To be fair, I kept my scenarios to “in-product functionality” and there are some scripts to help handle this kind of thing in SCCM 2007…, but why mess with scripts when the product has such a nice feature built right in and fully supported?

I should also note that content is not removed from the DP just by removing it from the DP group. You either have to delete it from the DP via the SCCM UI before removal, or format the ex-DP if you don't care. I did a modification of this post to make that more clear.

“Dial Me In Baby” and the other magical files of Configuration Manager

Mike Griswold — Wed, 06 Feb 2013 13:07:00 GMT

Back in the SMS 2.0 days I was doing phone support and I would often have to listen to statements of disbelief when I told customers to create a Dial_Me_in_baby.sms file in order to enable logging to troubleshoot their issues. While that file is no longer needed (all server logs are turned on by default) I thought I would do a short post on the magical files of SCCM. The files who mere existence affects the behavior of our product.

Dial_Me_In_Baby.sms

In the old SMS 2.0 days server logging was not enabled by default. It could be enabled component by component, but that was a pain. The other option was to create an empty text file in the root of the C drive called Dial_Me_In_Baby.sms then stop and start the SMS Executive service. On startup it would see the file and enable logging for all components, with default log sizes.

Die_Evil_Bug_Die.sms

This log was similar to Dial_Me_In_Baby except that it changed the logging level to include debug level logging. Not many folks realize that there are multiple levels of server logging on SMS/SCCM and use of this file was one way to get additional details in the logs (as if all of you want MORE detail in the logs). For some background on these two files see http://www.myitforum.com/articles/1/view.asp?id=3918

SkpSwi.dat

This file is in use today and is used by configuration manager to avoid inventorying itself. When a software inventory is being run and the client agent is recursively walking through the directory structures on the hard drive it checks each folder for the existence of this file. If the file is found then inventory of that that directory and all sub directories is skipped. It is usually hidden but if you look for the hidden file on one of your clients you should find it in a few places, the cache directory being one of them.

No_SMS_On_Drive.sms

Ideally this would never be needed, but the ideal and the real are not always the same, and thus it exists. There are several points in deployment of SCCM server roles, such as a distribution point, when you want to keep SCCM from using one drive partition. In most cases the default SCCM behavior is to choose the NTFS formatted drive with the most free disk space. If you don’t want a specific drive to be used then make a No_SMS_ON_Drive.sms file on the rot of the partition to be skipped, and it will be removed from consideration by the SCCM process.

Manual removal of the SCCM client

Mike Griswold — Wed, 02 Jan 2013 18:21:42 GMT

As much as I love it, it may occasionally be necessary to remove the System Center Configuration Manager client. I recently had a customer who could not get a machine to upgrade from 2007 to 2012 and after attempting many things we did a manual clean down of the client then the 2012 client installed just fine. If you need to remove the client you can do so fairly easily by running ccmsetup.exe /uninstall. Ccmsetup should exist on all clients, usually under the windows folder. In the event that the command line doesn’t work here is a list of things I usually check and remove to manually clean-up all the traces of the client so I can try a fresh install.

1. SMS Agent Host Service

2. CCMSetup service (if present)

3. \windows\ccm directory

4. \windows\ccmsetup directory

5. \windows\ccmcache directory

6. \windows\smscfg.ini

7. \windows\sms*.mif (if present)

8. HKLM\software\Microsoft\ccm registry keys

9. HKLM\software\Microsoft\CCMSETUP registry keys

10. HKLM\software\Microsoft\SMS registry keys

Permissions to Create a collection

Mike Griswold — Mon, 19 Nov 2012 21:31:45 GMT

I had a customer doing some custom permission setting in System Center 2012 Configuration Manager the other week and after adding folks to a few existing security roles all was good except that these limited rights users could not create collections. If you have looked at all the possible perms in ConfigMgr 2012 you may have seen that there are a lot and while you could test and figure this out, I figured I would share the answer to save everyone else a bit of time.

To create collections a user needs the following permissions:

Collection

Read
Create
Modify Folder

DP converts, but content fails

Mike Griswold — Tue, 23 Oct 2012 14:07:00 GMT

I hit an odd issue with a customer recently that was not easy to figure out or troubleshoot so I would like to share the problem and solution in hopes that others can avoid the pain we had to go through.

The issue is, in general, very straight forward. The customer had several existing System Center Configuration Manager 2007 distribution points (DPs) which they wanted to upgrade to be System Center 2012 Configuration Manager DPs as part of their migration from the old product to the new. The DP migration job ran and converted over the DP but none of the content was successful in conversion, which was really the point of the conversion in the first place.

Before I get into the gory details let me say that I have had numerous customers convert DPs and content, so why this failure occurred I don’t know. It might have been something in the environment, it might have been a product defect, or it might have been a solar flare at the wrong time causing an electrical disruption. In any case, the solution was so easy once we figured it out that we never bothered to spend time trying to find root cause.

The early symptom of the problem was a 2389 status message that indicated a failure to connect to the DP. The logs seem to indicate some kind of WMI failure, which may not really be the problem. After a bit of other troubleshooting steps we managed to follow these fairly easy steps to resolve it:

Open up SQL Server Management Studio
Run the following query against your ConfigMgr database, where <ServerName> is the FQDN name od the DP you are having problems with:

select * from DistributionPoints where ServerName = ‘<ServerName>’

Make note of the corresponding DPID for your problem (in this example I will call it 122389)
Using the DPID returned form the query create an empty DPU file with the DPID as the file name

example: 122389.dpu

Put the file in the \Microsoft Configuration Manager\inboxes\distmgr.box

That’s it. You should start seeing the content converted on the DP. One query…, one DPU file…, problem solved! Why it happens I’m still curious to know but I need another customer who is experiencing it to hire me to investigate it. If you are a premier customer who wants to spend their premier hours on me and you have this issue, contact your TAM and I will be there in 1-4 months.

404 for Driver packages, can’t find content.

Mike Griswold — Wed, 19 Sep 2012 15:42:23 GMT

Driver management has never been a fun aspect of Configuration Manager. It is one of those necessary evils to enable a bigger solution of great OS deployment. Done according to product design it consists of 3 general steps:

Import drivers into driver catalog
Add drivers to driver packages
Add boot critical drivers to WinPE images

Adding drivers to the driver catalog can, if not done with foresight, become a big mess. Some advice floating around the net recommended avoiding this mess by skipping step 1 and just creating a flat directory structure and pointing to it as your source for your driver package. To my knowledge this was never recommended by Microsoft, or supported as a proper driver management technique, but it worked and it is hard to argue with something that works and saves you time…., until now.

Under System Center 2012 Configuration Manager this method is blocked in the UI. If you try to make a driver package and point to a directory that already has files in it, you will get an error. However, if you migrate what you had under SCCM 2007 to 2012, the driver packages will migrate just fine and all will seem good..., until you run your first task sequence that uses those driver packages.

When you run that task sequence you will fail to find content for the driver package. If you look into the smsts.log you will find a 404 error being raised when trying to find the driver package contents. This is because the new single instance storage model on the DP is not compatible with the unsupported manor in which the driver packages were made. The solution is to go back to the supported method of driver management, using step 1 from above, and manage the “mess” of drivers as best you can.

Sorry for the bad news folks. The testing for the new features in ConfigMgr 2012 apparently didn’t go over testing all the unsupported scenarios out there, no matter how popular.

An easier way to create packages and programs

Mike Griswold — Thu, 06 Sep 2012 17:14:24 GMT

Today’s tip is one which many folks already know, but surprisingly many folks, even those who have used the product for a long time, have some how missed. Due to some work I put into this many years ago it holds a special little place in my ConfigMgr admin heart.

If you use any version of System Center Configuration Manager (SMS, ConfigMgr, SCCM) then you have probably created some packages and programs to deploy software. Have you ever noticed the option (varies based on product version) for creating a package from definition? That option was originally placed there so that software makers, such as Microsoft, could provide an easier way to deploy the product by you, the ConfigMgr admin. Along with the binaries of the product they could also supply a file, called a package definition file, which would auto populate some fields in ConfigMgr such as product name, version, proper command lines, etc. Originally these files were a .PDF extension but, for reasons I am all figure out, we changed that to be a .sms extension.

So.., great concept. You grab the files from the software maker, import the package definition file to create the package and program details in ConfigMgr, then you point the newly created package at your source files and start distributing software. The catch is… that it didn’t catch. Most companies and products did not bother with the creation of package definition files. Then along came our friend, the MSI.

With MSI technology picking up we saw the opportunity to help the ConfigMgr admin use this package definition concept. Code changes were made and now you can reference an .MSI as well as a .SMS or .PDF file for package and program creation. No longer must you depend on the software maker to create a special file. If they have an MSI then you can reference that and ConfigMgr will extract all the necessary data out to create the package and programs you need.

Next time you need to deploy software, check this out and see if it helps you take a few steps out of the deployment process.

Fast policy evaluation only for new machines

Mike Griswold — Thu, 02 Aug 2012 12:07:00 GMT

Many of my customers are in similar situations where they do not include application deployment in their OS imaging process but instead rely on Configuration Manager to deploy apps after the OS is up and running. The biggest complaint I hear is about how slow ConfigMgr is to do this and thus people try to speed it through various things like faster collection update intervals and more aggressive client policy polling intervals. The downside of these more aggressive practices is that there is more churn and load on the network and server infrastructure, just to support these few new machines as they are initially built out.

In a discussion with one of my customers I hit upon a solution to this situation using the new capabilities of the ConfigMgr 2012 product. The general idea is to have aggressive schedules only for machines in the process of being setup but less aggressive schedules for the rest of the machines.

Overview:

Set (only) necessary collections to do incremental updates
Enable delta discovery for systems
Set default client agent settings to policy interval of 5 minutes
Set "standard" client policy interval to 60 minutes, precedence of 2
Set "setup" client policy interval to 5 minutes, precedence of 1
Deploy “setup” interval at collection with members created in last X days
Deploy “standard” policy to a collection of all clients, such as “all systems”

Outcome:

A new machine will get the aggressive default policy polling interval of 5 minutes and keep checking for new software deployments. Once AD discovery picks up the machine via delta discovery it will be added to the collections via incremental updates to start getting software. It will also join the “setup” collection and get a policy that keeps its policy polling interval at 5 minutes. After a set time (1 day in my example below) when setup should be complete it will move out of the setup collection but get the standard policy which puts it back on a normal 60 minute policy polling interval, causing less churn.

Details:

The key to this setup is the collection query rule for the setup collection. The following query should give you all machines added to Configuration Manager in the last day:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,

SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,

SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client

from SMS_R_System where DateDiff(dd,SMS_R_System.CreationDate, GetDate()) <1