Organize Collections with Drag and Drop

One of the plans we've had since I took over the administration of Configuration Manager is to organize the objects in the admin console.  SCCM makes it easier than SMS since it supports drag and drop.  The catch is that it only supports it with certain types of objects.  Collections is one of the object types that doesn't support drag and drop.  The only way I found to reorganize collection objects was to make a link of a collection to a second collection.  Making this link actually makes a 2nd instance of the collection appear in the hierarchy.  Then you can go back and safely delete the original collection.  The other option is to use a Microsoft provided SMS tool called CollTree.  Yes, the program does work with SCCM.  After downloading the SMS 2003 SDK you can compile the executable from \Program Files\Microsoft Systems Management Server 2003 SDK V3\Samples\VB\CollTree\CollTree.vbp  It's not as great as if Microsoft had built this functionality into the Admin Console, but at least it works!  Download a compiled version of CollTree here: http://myitforum.com/cs2/blogs/bleary/attachment/68439.ashx

Credits to Brian Leary for pointing out this useful tool: http://myitforum.com/cs2/blogs/bleary/archive/2006/12/01/colltree-drag-and-drop-collections-for-sms-2003.aspx

query collection based on file existing on machine

At my company we wanted to create a system where developers could opt in to receive a copy of the nightly build of the software they were working on. In the first part of this project we create a collection based on the software inventory of a particular file. By default SCCM looks for any *.exe's on client systems. Rather than add another file type, we created a dummy exe as the criteria for our collection:

Criterion Type: Simple Value

Where: Software Files – File Name

Operator: is equal to

Value: Filename.exe

Equilivent in wql:

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 inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SoftwareFile.FileName = "Filename.exe"

Day One: The SMS Admin has left the building

The SMS Admin has left the company. There are no useful documents. If your lucky there are some buried in the sea of network shares, but most are outdated or poorly written. It’s Mission Impossible. Your mission, should you choose to accept it, is to take over SMS and all of its associated projects and duties without bringing down the company. No this isn’t really optional, but it’s the position I found myself in today, and with patch Tuesday already 3 days old the task wasn’t going to disappear to the bottom of my to-do list.

So what does one do when the reins of SMS have been handed over and the old admin isn’t around to ask questions? I had a little experience with SMS since I helped implement the OSD feature pack. One of the other Admins had experience since he helped install it (3 years ago). Admin number 3 attended a couple of classes, but really didn’t have a clue regarding SMS. It was crunch time and today was day one.

Step one: Install the SMS console. This can be done on any machine and is used to connect to the SMS site server and DP. You can cheat and use the console installed on the server, but who wants to do that? It’s on the SMS CD but in the real world your SMS server is version 2003 and SP2 is installed. The CD won’t help since the latest version is needed which you can get direct from Microsoft: http://www.microsoft.com/downloads/details.aspx?familyid=37B20B4B-DFEC-464D-908B-5D783E2370D3&displaylang=en

Run SMS2003SP2.exe /x

Autorun.exe will get the client tools installed and contains the latest version. It’s probably backwards compatible. So even if your previous admin wasn’t up to par, you can connect to the site server and administer SMS

Step two: Start the console and connect to your central site server. Use the machine name when prompted not the site code. If you didn’t get console on your local machine you can cheat and RDP to the SMS server. You’ll need admin rights either way.

Step three: Look around and see what the previous admin left.

There are 3 primary terms to get familiar with in SMS. 1- Packages 2- Collections 3- Advertisements.

Packages:

A package is a group of source files necessary to run a particular program. In most cases you want the setup program files. It also contains the command line to run. A typical command line is msiexec /I foo.msi /qb. Go ahead and make one. You’ll be asked to update the Distribution Points with it. Nothing is going to the clients so feel free. A good harmless one has no source files just a command line: notepad.exe. Just like start>run>notepad.exe this will cause notepad to pop up. If you choose the option to run it under the system account instead of the local user account then nobody will see it, but it should appear in task manager when the all users option is checked.

Collections:

Collections are simply a group of computers. It can have one or many computers in it. Look for an existing test collection with computers you are familiar with. Better yet, create a new one with one of your test machines in it. You’re not gonna screw anything up by creating one. Don't mess with any of the existing collections some of them are created with a SQL query.

Advertisements:

Advertisements tie Collections and Packages together. This is where you can do damage. Creating an Advert involves telling SMS which packages should go to which collections and when. The wizard is pretty self explanatory, just make sure you pick your notepad package and the collection is your test collection.

Congrats you just did your first SMS deployment on the test server and didn’t bring down the company. (you weren’t practicing on the production server were you?). I’d call this a successful mission. Coming up in Day 2: What the hell is going on with the SMS environment?