Hi everyone! I know I've been joking a lot lately about getting back to posting to my poor, neglected blog, but I had no idea it had been SOOO long since I've posted anything here!

To be fair, I've been pretty darn busy for the past year or so. Moving to Boston, taking a gig as the MDOP Content Publishing Manager and trying to get my head wrapped around a lot of cool new products after moving out of the Configuration Manager team. The good news is that I've got a few posts up my sleeve and will be posting them soon so I hope you're ready to hear about some "MDOP stuff"! If you have any burning questions or desires to see me blog about in that space just let me know and I'll do my best to accommodate.

Microsoft is building a worldwide community of IT Pros who want to share their frank opinions about our products (primarily Windows Server, Microsoft System Center, and Microsoft Forefront). We call it the International Customer Advisory Board (ICAB), and by the end of this year, we will be 1000 IT Pros strong.

Beyond troubleshooting issues, hearing about new offerings before they become common knowledge, and becoming a trusted Microsoft partner—never a bad thing to have on your resume—the networking opportunities are legion. As a part of the ICAB, you join a community of distinguished professionals that spans the globe. Want to work in Paris? Hong Kong? New York? The ICAB has members in all those cities, and in 50+ countries across the world.

The Configuration Manager Cloud Search service is now up and running and we could really use your feedback on the quality of search results. For example, are we hitting the right blogs? Are the TechNet searches picking up the right results? Right now, the search tool performs scoped Bing searches across a variety of Configuration Manager related data sources including:

I haven't posted to this blog in quite some time so some of you might be curious what I've been up to. I guess the short version is that I've been pretty busy—I got a new job and am no longer part of the SMS/ConfigMgr writing team. For those of you in the SMS community who noticed that I wasn't being very active, or knew that I'd taken that position, and e-mailed your concern about where I was going and what I was up to, it is sincerely appreciated.

The longer version of this story is that about a month ago I accepted the position of content publishing manager for the App-V and MED-V documentation teams. I realize that this makes this blog post is a little belated, but to be fair…I've been busy! In addition to managing those teams, I will still be doing some writing when anything to do with Configuration Manager integration comes up so I won't be completely leaving the world of SMS.

While the App-V documentation has been online for some time, this month the MED-V documentation was posted to TechNetfor the first time ever. And just like the smsdocs feedback alias for Configuration Manager documentation feedback, you can always send an e-mail to the appvdocs or medvdocs @microsoft.com feedback aliases to start a conversation with us about the docs!

If you read the post on how to customize SMS 2003 Resource Explorer icons, then you'll have the history behind why I decided to figure this out. You probably also noticed that I said not to try those steps on Configuration Manager 2007 sites and wondered why.

After figuring out how Resource Explorer decides on which icon to display in SMS 2003, I started poking around a Configuration Manager 2007 installation…and noticed that the files I was looking for either didn't exist or didn't work the same way. Sure, you might find some of the files that I referenced for configuring SMS 2003 icons, but they won't help you out in this particular endeavor. Resource Explorer was recoded for Configuration Manager and changes were made to how these icons are assigned.

In fact, if you try to do it the other way, you'll end up with things like this in your resourceexplorer.log file:

The 'resource' (Microsoft.ConfigurationManagement.AdminConsole.UIResources.SMS_G_System_PHYSICAL_MEMORY.resources) was not found.\r\nSystem.Resources.MissingManifestResourceException\r\nCould not find any resources appropriate for the specified culture or the neutral culture. Make sure "Microsoft.ConfigurationManagement.AdminConsole.UIResources.SMS_G_System_PHYSICAL_MEMORY.resources" was correctly embedded or linked into assembly "AdminUI.UiResources" at compile time, or that all the satellite assemblies required are loadable and fully signed.\r\n at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)

"Linked into assembly AdminUI.UiResources" …eh? what? After giving the log the 'what look' for about 30 seconds, I decided it was time to call for back up. Its times like these that make me happy to work on the team that I'm on—I just had to find the developer who made the changes and/or knew enough about the process to give me a hint. Luckily, that person appeared from the mists (OK, really the third floor of my office building) with all the answers I was looking for—cue Jun Wang 'developer extaordinaire'.

So, after some wise words from Jun, it became apparent that I should forget everything I knew about how to do this in SMS 2003. The files you should concern yourself with in Configuration Manager sites are the adminui.uiresources.dll and the managementclassdescriptions.xml files:

The adminui.uiresources.dll file (located at .\Microsoft Configuration Manager\AdminUI\bin\adminui.uiresources.dll) contains all of the icons used in Configuration Manager's implementation of Resource Explorer.

The managementclassdescriptions.xml (located at .\Microsoft Configuration Manager\AdminUI\XmlStorage\ConsoleRoot\managementclassdescriptions.xml) is the file that tells Resource Explorer which icon to display.

Important: As usual with "hacks" like this, the information in this post is in no way supported by Microsoft (or me) and should only be used at your own risk if you want to fancy up your Resource Explorer icons similar to how Flo tricked out her name tag on those insurance commercials on TV.

If you want to change the icon that is displayed for a particular inventory class, you need to pop open the managementclassdescriptions.xml file and change some .xml (make sure you back up the original first!). For this example, I just opened it with notepad.exe and scrolled down until I found the class I wanted to modify. In this example I'm using the CD-ROM class and the snippet in the .xml about it looks like this:

See how the image description says to go look in the AdminUI.UIResources.dll file and grab the icon named System to display for the CD-ROM class in Resource Explorer? Luckily, the icons are listed in the .xml as names and not ID's so we don't have to open the .dll and poke around to find an icon we like, we can just peruse the .xml for a name that sounds like something we're after…how about CD_Rom? Changing System to CD_Rom for that <ImageResourceName> line, saving the .xml, and then restarting Resource Explorer returns this result:

Before:After:

That's better, and now you know how to change the default icons in Configuration Manager's version of Resource Explorer.

Adding custom icons is a bit more problematic. If you open the AdminUI.UIResources.dll file in Visual Studio, the icons are not listed the same way as they were in the SMS_RES1.dll file (the SMS 2003 .dll holding the icons) and you also can't add custom icon resources to that file. To add your own custom icons in Configuration Manager, you have to create a new .dll file, add your icon to that file, and then properly reference your custom assembly and icon name in the managementclassdescriptions.xml file.

That seems just a little bit too complicated to me to throw in at the end of this blog post and I'll have to write that up seperately. So, until then, that's all I've got to say about changing Configuration Manager 2007 Resource Explorer icons.

I've done quite a bit of hardware inventory modifications in my time and while it's great to see the new information displayed in Resource Explorer, it has always kind of bothered me that the new classes always had the default icon while some of the other inventoried information had more descriptive, and lets face it, cooler looking icons. As I implemented more and more hardware inventory modifications, it also became a challenge for me to remember just how I pulled that information—was it a registry key, a NOIDMIF, a script…you get the idea. Wouldn't it be nice to have a custom icon to remind me where that data came from I thought. This issue would crop up every now and then which sent me on a wild goose chase looking around for a while on the net. I never really came across anything very helpful and eventually I'd move on to something else. While this is seemingly very minor issue, it has always bothered me that I couldn't figure it out. And then one fatefully day recently someone on the myITforum SMS e-mail list (subscribe here) had a problem that caused the non-default SMS 2003 Resource Explorer icons to revert to the standard default icons. Now my quest to change Resource Explorer icons had taken on new life, and actually had a basis in something useful in helping out someone, so it wasn't just a matter of me trying to do something cool in figuring this out.

Important: Before reading on, understand that the information in this post is in no way supported by Microsoft (or by me in general for that matter) and should only be used at your own risk. If you're not comfortable mucking about with the steps in this procedure and performing icon disaster recovery in the event something goes wonky, please do not attempt! If your icons are not broken and you aren't after the cool icon effects for whatever reason then it's probably not worth the risk.

Disclaimer out of the way, here's the good stuff. To understand how SMS 2003 decides which icon to display for hardware inventory information displayed in Resource Explorer, you need to have a clear understanding of the three pieces of this puzzle: the sms_res1.dll file, the sms_schm.mof file, and how this information is stored in WMI on the site server.

The sms_res1.dll file contains all of the icons that can be displayed by default, and is located in the <install drive>:\SMS\bin\i386 directory. This file contains around 300 icons and some other assorted information that I'm not going to talk about here because it's just not relevant. If you open up the .dll in Visual Studio you'll see something like the below snippet, and if you then expand the icon node, you'll see the list of icons that it is possible to pick and choose from when using a standard icon:

The sms_schm.mof file is used to map each of the hardware inventory classes displayed in Resource Explorer to a specific icon stored within the sms_res1.dll file. It also lives in the <install drive>:\SMS\bin\i386 directory. Here you can see the part of the file where the CD-ROM information is assigned icon #316 in the SMS_RES1.dll file:

The sms_schm.mof file stores mapped icon information for inventory classes in the IconDLL and IconID qualifiers for their respective WMI namespaces under root\sms\site_<site code> when it is compiled. You can see in the snippet below that the CD-ROM class is set to display icon #316 (the CD-ROM icon) in WMI and as stored in the SMS_RES1.dll file:

If you're looking in SMS 2003's Resource Explorer and see only the default icon for everything, then one of those three pieces has gone catawompus. To find the culprit, you can run a cursory visual check of the files to see if something has become corrupted. If it all looks OK, then back up all of these files to somewhere safe and recompile the sms_schm.mof file by opening up a command prompt, navigating to the directory that sms_schm.mof is located and then running this command: MOFCOMP sms_schm.mof. Restart the computer and Resource Explorer should be back to displaying the default, 'non-default' icons for those classes lucky enough to have been assigned one. If it isn't, then you might need to grab another copy of the sms_schm.mof file and/or sms_res1.dll file from the installation source files and try again. If that doesn't work, then your WMI might be corrupt or some other issue beyond the abilities of a blog post to help you and you need to burn a support call.

That issue resolved and out of the way, I decided that I would continue on my quest for custom icons in Resource Explorer. If all of the Resource Explorer icons are stored in the sms_res1.dll file and are called by the sms_schm.mof file then what's to stop me from changing a default icon to one of the other icons stored in the sms_res1.dll file? For that matter, what's to stop me from adding my own custom icons? Turns out, nothing lucky enough for me.

First things first, you need to find the icon that you want to use and it's associated IconID as listed in sms_res1.dll. To do this, you'll need to use Visual Studio to pop open the sms_res1.dll file and then poke around until you see an icon that you like. Take the icon's IconID (the number of the icon in the .dll), change the appropriate class IconID value in the sms_schm.mof file accordingly, and then recompile it.

That's great for pre-existing inventory classes, but what if you want to change the icon for a custom inventory class? No problem, just open up the sms_schm.mof file and add in a section at the bottom for your class. Below is the addition I made for the custom physical memory MOF edit to my sms_schm.mof file and you can use it as a template, just ensure the group name and class information matches your custom MOF edit:

Having the custom physical memory class information displayed using one of the default icons is OK, but wouldn't it be nice to have the icon actually look like RAM? Easy enough, just add the snippet above for the class to the sms_schm.mof file and change the class IconID property to display the RAM icon as stored in sms_res1.dll (IconID: 306). Recompile the sms_schm.mof file on the site server and hopefully the icons change the next time you open or refresh Resource Explorer. If not, restart the server and then here's what you should see in Resource Explorer (before and after):

Before: After:

Cool eh?

Using one of the predefined icons is handy, but if you don't see an icon that you like stored in sms_res1.dll, or you want to add your own custom icon for whatever reason, that's easy to do too. Using Visual Studio again, open up the sms_res1.dll file and add the icon of your choice to the file and save it. To do that, open the .dll in Visual Studio, right-click the Icon node, select Add Resource, ensure Icon is selected and then click Import. Browse to your favorite icon file and click open to add it. The new icon will appear in the list with an assigned ID and be highlighted in a box so you know which one you just added (remember the new IconID number!).

Next, make the appropriate changes to the sms_schm.mof file and compile it (MOFCOMP <path>\sms_schm.mof). Custom icons allow you to verify which classes are custom MOF edits and/or know where the custom class information came from depending on which icon you've decided upon for specific MOF editing techniques (registry, WMI, script, etc…). For example, this one came from a registry key:

Oops. That's not a registry icon (and didn't come from the registry either, but I'm using some poetic license here)! The registry icon is a default icon in the sms_res1.dll and wasn't very interesting to me, while Bill the Cat is one of my personal hero's. OK, kind of off-topic there, but it shows how you can use any icon that you want to and besides, couldn't the world use more Bill the Cat?

If you'd like to make an icon change, but don't want to permanently modify the sms_schm.mof file, then you can just go directly into WMI for that class and change the IconID to something more to your liking. If a class doesn't have the IconDLL or IconID qualifiers (both are required), just add them, but remember that recompiling the default sms_schm.mof file will result in the class displaying its original icon in Resource Explorer. Also know that at the top of the sms_schm.mof file is the #pragma autorecover command. That means if WMI is rebuilt on the site server for whatever reason, and you haven't made your changes in that mof file, the icons will all revert back to their installation defaults when the sms_schm.mof file is recovered.

So, there you go, mystery solved—for SMS 2003 sites. Don't even think about trying to use this post as a guide to change Resource Explorer icons for a Configuration Manager 2007 site as the process isn't exactly the same, but don't worry; I've got you covered on how to do that in another blog post that's coming soon.

If you've ever installed, or even thought about installing, a Configuration Manager site, or site system requiring IIS on a Windows Server 2008 computer then you've probably had a look at the How to Configure Windows Server 2008 for Site Systems help topic in the Configuration Manager 2007 Documentation Library and then spent some time installing and manually configuring IIS 7, then installing WebDAV for IIS 7, and then spent some more time configuring WebDAV afterwards. If you only have to do this one or two times it's not too big of a deal, but because I'm constantly installing Configuration Manager lab machines on Windows Server 2008, going through the motions of installing and configuring IIS 7 can get repetitive. Not to mention that I always seem to leave out a bit of the configuration that sends me back to installing a missing feature later. After about the thousandth time configuring IIS 7 manually, I thought to myself "there's got to be a way to script this and save some time". If you've had the same thought then this post is for you. After some looking around, I couldn't find the steps to install and configure IIS 7 to support Configuration Manager installations anywhere so I decided to just figure it out for myself (and consequently, for you as well ).

My first stop was figuring out how to install IIS 7 via the command line. Instead of using sysocmgr (used to install IIS 6), Windows Server 2008 has a handy server manager command-line tool that is used to install Windows Server 2008 roles and features (could be any role or feature you want and not just IIS btw). If you want to install a single role or feature then you can just use the command line, but when you need to install multiple roles or features, you have to create an .xml answer file. Sounds a little daunting, but it's really not too bad. I just used notepad to create an answer file using these instructions. I covered all of the requirements defined in the Windows Server 2008 How To topic in the documentation library for every possible requirement other than the last bit about modifying the requestFiltering section on BITS-enabled distribution point computers. Here's what I came up with:

To kick off the IIS installation using just the answer file, open a command prompt (right-click command prompt and select run as administrator) and then enter a command in the format below. I saved the log file as a .log instead of a .txt so I could use SMS Trace to watch the IIS installation action progress in the log instead of the counter in the command shell window, but you don't have to):

ServerManagerCmd.exe -inputPath <answer.xml [-logPath <log.txt>]

After running that command, you should see something similar to this:

Moving along to WebDAV which I thought was going to be a bit more of a challenge. Not only do you need to install the applicable version of WebDAV (either x86 or x64), you also need to create an authoring rule and configure other settings post installation. Luckily, another tool came to my rescue: appcmd.exe. This tool allows you to configure IIS 7 settings from the command-line…handy.

Armed with an IIS 7 installation answer file and the servermanagercmd and appcmd tools, I was ready to write the script to automate the process. I also wanted the script to auto-generate the IIS 7 answer .xml file for me so I wouldn't have to carry around an extra file everywhere (those .xml files can get heavy and I'm not as young as I used to be). Before I get to the script though, here are some caveats if you're planning on using my script 'as is':

The script relies on having the applicable WebDAV installation .msi in the same directory that the script is started from (in my testing I put the script at the root of C:\ and used the x86 version)

The script assumes that everything is installed on the C:\ so if you're using a different drive you'll need to tweak the script as necessary

There is no error checking in the script as I am only planning on using this in my lab for clean installations

You can't use this script if you've already installed IIS 7 as it will fail to reconfigure IIS

This script is provided 'as is', your mileage may vary, test it in a lab to ensure it does everything you need it to before using it in production, etc...

So without much futher adieu, here's the PowerShell script…what? Don't have powershell installed on your Windows Server 2008 computer? No problem, just do this, open a command prompt (run as administrator) and run: ServerManagerCmd –install powershell and then continue after PowerShell installs. To run the .ps1 you'll also need to relax the PowerShell script execution policy since this script won't be signed. To do that, open up PowerShell and run Set-ExecutionPolicy Unrestricted. This setting will allow you to run unsigned scripts, but will also lower security for running scripts unless you change the security setting to a higher level later.

OK, moving on, here come the scripts. I've shown how to do this using PowerShell, .vbs, and .bat, but I do not recommend C&P'ing these scripts as who knows what word-wrap as done to them. If you want to use these scripts, you should probably download the .zip containing all of them from here. The .zip contains the un-commented PowerShell (IIS7.ps1), visual basic script (IIS7.vbs), and a batch file (IIS7.bat) that all do the same thing except that you have to manually create the answer.xml file yourself when using the .bat.

Here's the PowerShell version. I've inserted comments in this post to tell you what is going on as the script progresses:

No, we still haven't found a way to make such a large documentation set easily printable, but now you can download the Configuration Manager help file locally and also update the help installed on Configuration Manager consoles so that it can be nearly as up to date as the help displayed on the Web. More information about it can be found here:

Dan Boldo has updated the TechNet Asset Intelligence forum with some great information--the System Center Online catalog is now fully operational. This means that if you have deployed Configuration Manager 2007 SP1, your Asset Intelligence synchronization point site system role can now be used to synchronize with System Center Online to download (and upload if you want) software catalog information!

The first thing that you need to do before deploying SQL Server 2005 and SQL Server 2005 SP2 using a task sequence is to create the packages and programs that the task sequence will use. If you haven't done that yet, go read part 1 of this post!

After the required packages and programs are created, and successfully distributed to distribution points, we can get started. I'm going to break this post down into the following sections:

Creating the task sequence

Advertising the task sequence

Monitoring the task sequence actions

Verifying the install did what it was supposed to

Creating the task sequence

The package source is just the SQL Server 2005 RTM installation media. The interesting bits are all in the program properties.

Leave Install a single application selected. Click the Browse button and select the package that you want to use and then select the program that you want to deploy (this is the package/program that installs SQL 2005 RTM for me). The red X should now be a green check mark.

Highlight the top group name again and click Add\New Group. Give this subgroup a name (I named mine Install SQL Server 2005 SP2). Drag the new group underneath the previously created task sequence group.

Highlight that group name, and then click Add\General\Install Software.

Leave Install a single application selected. Click the Browse button and select the package that you want to use and then select the program that you want to deploy (this is the package/program that installs SQL 2005 SP2 for me). The red X should now be a green check mark.

If all goes well, you should now see something like this screen shot in the Task Sequence Editor Window and you can save and close it:

Advertising the task sequence

Of course, task sequences do no good if you don't advertise them to clients.

Right-click the newly created task sequence and select Advertise to start the New Advertisement Wizard.

Ensure the correct task sequence is selected and click Browse to select the collection that you want to advertise this task sequence to. If you don't want this advertisement to include subcollections (I don't), then de-select the Include members of subcollections option.

On the Schedule page, configure the schedule that you want this advertisement to use. Because I'm doing this in a lab and I want it to install right now (or as close to it as possible), I create a mandatory assignment time for as soon as possible. I also check the options to Ignore maintenance windows when running this program and Allow system restart outside of maintenance window.

On the Distribution Points page, you need to select an option for how the package contents will be accessed. Because I like to ensure that all required files are present before beginning major software installations to avoid transient network issues during installation that could cause the install to fail, the two options I'm looking at are: Download all contents locally before starting task sequence and Download content locally by running task sequence. From those two available choices, I'm going to pick Download content locally by running task sequence and here's why:

When you configure an advertisement to Download all contents locally before starting task sequence, the content is stored here in the client cache directory—and they are not deleted after the task sequence finishes:

When you configure the task sequence advertisement to Download content locally by running task sequence, the content is stored in a temporary task sequence directory—and they are deleted when the task sequence finishes:

Technically, the install will run successfully using files from either location (and most likely even if you run it from a distribution point), but the problem I have with using the client's local cache directory is that the source files are not removed after installation. Even though I'm using a setup.ini file located on a hidden share and not located with the source files in this instance, you might not always do that and a savvy user could get ahold of those cached SQL Server setup files, proceed to run amok on the network, and then I've got a bunch of unauthorized SQL installations to account for. Besides that, it just takes up a bunch of hard drive space on clients unnecessarily (over a gigabyte in this case for SQL Server 2005 and SP2).

On the Interaction page, select Show the task sequence progress.

Finish out the wizard to complete the advertisement process.

Now, you can just wait until the targeted computer retrieves the machine policy that contains the advertisement information for the task sequence to kick off, but I'm not that patient so I manually initiate a machine policy retrieval & evaluation cycle to get the party started.

Monitoring the task sequence actions

There are a couple of ways to monitor the task sequence as it goes through the motions that you have configured for it. You can use the Configuration Manager console and reports to view the status of the task sequence execution or you can watch the progress from a targeted machine…or both I suppose. I'll walk you through each of these methods next.

As soon as you advertise the task sequence to a collection, the Configuration Manager console OSD home page updates and displays the status of the new task sequence advertisement:

As the task sequence execution proceeds, clients send in task execution status messages, and the home page refreshes, you can follow the status in the console using the color coded chart:

If you don't want to wait, or you want to see an individual computer's task sequence execution progress, you can view Web reports that detail the progress by clicking the task sequence name in the console. There are a total of three reports that drill down and display more detailed information about the task sequence status:

Status summary of a specific task sequence advertisement. This report shows the status summary of all resources that have been targeted by an advertisement.

Drilling down by clicking an execution state value you get:

All system resources for a specific task sequence advertisement in a specific state. This report will show a list of computers that are targeted by the specific task sequence advertisement and are currently in the specified state.

Click a computer name for that particular computer's status gets you:

History – Specific task sequence advertisements run on a specific computer. This report shows the status for each step of a task sequence. If no record is returned, it means the task sequence has not yet started.

The last one is the one that I like. It displays detailed information about each step taken during the task sequence execution for a particular computer. I like to open this report for a test computer and watch the actual task sequence in action by refreshing the page every now and then. Of course, nothing beats watching the task sequence execution at an actual computer that is running it though.

Monitoring task sequence execution from the client computer

After a client computer receives the task sequence notification policy it displays the notification in the system tray to alert you that it is going to run (I set a mandatory installation time of as soon as possible for this example):

You can follow the progress of these initial stages by watching the client's execmgr.log which hands off logging to the <install dir>\CCM\Logs\SMSTSlog\smsts.log file. Anyway, clicking the notification gives you the option to run the task sequence or wait for the countdown to complete. When the task sequence starts, installation progress messages are displayed on the screen.

The install software task (to install SQL Server 2005):

The restart computer task that comes after the install software task in the task sequence:

After the computer restarts, the task sequence waits for the Configuration Manager client to reinitialize and then continues on its merry way:

The install software task to install SQL Server 2005 SP2:

The restart computer task that comes after the install software task in the task sequence and we're all done:

Verifying the task sequence did what it was supposed to

The OSD home page gives you a good overall view of the task sequence status and by viewing the Web reports you can even more detailed information about whether or not the task sequence was successful. This part is just verifying that the task sequence did what it was supposed to do—install SQL Server 2005 and then SQL Server 2005 SP2.

On the targeted computer, open up SQL Server Management Studio (it is there now right?!), right-click the server name and click Properties. The General page of the server properties should look something like this:

Here you can verify some of those setup.ini file settings that we told SQL setup to use, and ensure that SP2 was successfully installed—the version number should be 9.00.3042.00. If it says something like 9.00.1399.06 (SQL Server 2005 RTM) then you know the service pack installation didn't stick. Here's a handy link while I'm thinking about it: How to identify your SQL Server version and edition.

You should also check the SQL Server setup and service pack setup summary logs. If you used my .ini file, then these logs are at the following locations respectively:

And that is that. This is just one example of how to use task sequences to install software outside of normal OSD tasks, but I hope it has been helpful and gets you thinking of other ways that you can use this powerful new feature of Configuration Manager. Happy task sequencing!!!

One of the coolest features (I think) of Configuration Manager is the ability to deploy software using task sequences, but because task sequences are generally associated with operating system deployment, a lot of people never really use them unless they're deploying new operating systems. Because of that, I thought I'd write up a few posts on how to use task sequences to install software, when not deploying operating system images, to kind of highlight the things you can do with it.

If you're not familiar with task sequences, then you should probably go check this link out first: About Task Sequences

One important paragraph in that topic that relates to this post is:

Although task sequences are essential for operating system deployment, they can also play a vital role in other Configuration Manager 2007 tasks. The power of task sequences lies in their flexibility and administrators can use these to configure client settings, distribute software, update drivers, edit user states, and perform other tasks independent of operating system deployment.

I install Configuration Manager site hierarchies all the time in my lab, and one of the prerequisites for installing a Configuration Manager 2007 primary site is a supported version of SQL Server to host the site database. Installing SQL Server 2005, and then SP2 on top of that, usually takes up a good bit of time and requires a few reboots so I thought this would be a good example to use. I also do most of my installations using scripted installation methods and finding a SQL setup.ini file to use to support Configuration Manager specific requirements was also hard for me to do so I've included that in this post as well.

One thing to take note of here is that task sequences that install software run normal Configuration Manager software distribution package programs and that's what the remainder of this post is about—creating the required packages and programs to install SQL Server 2005 and SQL Server 2005 SP2. These packages and programs can be advertised outside of OSD task sequences and will run just fine. Of course, you're probably now wondering why I'm writing a whole post about creating packages and programs and then using a task sequence to deploy them instead of normal software distribution. Here are a couple of reasons why:

The installation process is fully automated—including rebooting the computer. Chaining software distribution installations that require the computer to reboot is just generally not fun. Task sequences handle planned reboots with ease and ensure that all files are installed correctly with no files from a previous installation still requiring a reboot.

The entire task sequence installation is easily tracked. Each step along the way is viewable in Web reports and the overall status of the task sequence is displayed in the operating system deployment home page in the console.

The package source files are not leftover on the client machine after the task sequence runs (this depends on an advertisement setting that I talk about in part 2).

…and probably more things that I can't think of right now, but the above reasons are enough for me anyway.

The first thing that you need to do before deploying SQL Server 2005 and SQL Server 2005 SP2 using a task sequence is to create the packages and programs that the task sequence will use. This part is fairly straightforward software distribution stuff so I'm not going to go into much detail except to point out the important parts.

NOTE: Before using these programs to install software using a task sequence, ensure that you have tested them running as normally advertised programs. When programs run as part of a task sequence, user interaction is generally not possible. This means that if an error or warning dialog pops-up that you can't see, the task sequence will fail without completing the installation, and you'll have a hard time figuring out why!

Creating the SQL 2005 Package

The package source is just the files from the SQL Server 2005 RTM installation media that I've stored in a server share on my site server computer. The interesting bits are all in the program properties.

General Tab

First, there's the command line that I'm using that requires some explanation:

Servers\setup.exe /settings \\siteserver\sql$\SetupSQL.ini /qb

The actual setup.exe file is located in the Server subdirectory of the installation source files and I'm using the SQL Server setup /settings command line option to specify a setup.ini file for SQL Setup to use when during installation. Because you have to specify a complete path to the .ini file, and determining what that path will be at runtime can be difficult (especially when deploying through a task sequence), I've decided to use a hidden share on the site server to host the .ini file. That way, I always know where the .ini file is, and I can change it as required from a central location later without having to change the package source files. Another good reason to do this is because you don't want just anyone finding the source files and also getting the installation product key at the same time unless you like a lot of unplanned SQL installationsJ.

About the .ini file settings that I'm using

I looked around for a example of a SQL Server setup.ini file and couldn't find one that completely fit my requirements for installing SQL to support Configuration Manager so I made my own. I decided to just install everything that I thought I might ever need all the way up to Configuration Manager 2007 R2 installations.

The .ini file I'm using is here (rename the extension from .txt to .ini before using), but specifically, the .ini file does this:

I'm not specifying an installation key as the media that I'm using doesn't require it (not that I'd show you the key I used anyway!)

Installs SQL components to their default locations. I'm just doing this in a lab so I've commented out the installation directory options in the .ini file. If you want to change where the SQL bits are installed, just uncomment (take out the ;) and enter the locations you want to use.

The ADDLOCAL line tells SQL to install:

SQL database components

SQL replication bits (in case I want to play with SQL replication later)

Run all of the SQL services under local system (not a SQL Server best practice, but this is for a lab installation and I don't want to deal with setting an SPN for the account every time I use this .ini to setup SQL). I also set all the services to autostart.

Sets the collation of the installation to SQLCOLLATION=Latin1_General_CI_AS.

Configures the reporting services installation to the default configuration.

Sets the installation to use TCP/IP communication and not named pipes.

Ops out of error and SQM reporting for the instance.

Another option for this program command line could be an actual SQL Server setup command line like the one below (this is just an example command line and does not do what the .ini file I'm using does—this would all need to be on one line too):

Of course, that won't all fit in the command line text box in the program properties, so you'd have to write a .bat or .vbs or some other wrapper to pass the command line. Besides, setup .ini files are more TechSexy than setup command line options J

Note: If you're interested in customizing your own .ini file to use for SQL Server setup, you could take a look at the template.ini file that ships with the SQL Server setup files in the .\Servers\ directory. This template also gives command line examples and additional information about .ini file settings that I haven't talked about.

Requirements Tab

I always set the Maximum allowed run time (minutes) option to Unknown. This might cause the installation to run over maintenance windows, but if I'm going to deploy SQL Server I don't want it timing out on me and I should probably have a pretty good idea of which servers I'm sending this installation package to so I know what to expect.

Environment Tab

I set the program to: run whether or not a user is logged on, run with administrative rights, and run with UNC name.

Advanced Tab

I'm not going to advertise this program because I'm only going to deploy it through a task sequence, so I enabled the Allow this program to be installed from theInstall Software Task sequence without being advertised option.

Creating the SQL 2005 Service Pack 2 Package

The package source is just the SQL Server SP2 installation file stored on the site server computer. This package is much simpler than the actual SQL Server installation package, but I'll review what I'm doing to install SP2 here.

General Tab

The command line I use for the actual SP2 installation is just a normal command line install of SP2: SQLServer2005SP2-KB921896-X86-ENU.exe /quiet /basic /allinstances.

Requirements Tab

I always set the Maximum allowed run time (minutes) option to Unknown for service pack installations so it won't time out on me. Again, this might cause the installation to run over maintenance windows, but I'm OK with that.

Environment Tab

I set the program to: run whether or not a user is logged on, run with administrative rights, and run with UNC name.

Advanced Tab

I'm not going to advertise this program because I'm only going to deploy it through a task sequence, so I enabled the Allow this program to be installed from theInstall Software Task sequence without being advertised option.

So at this point, the required packages and programs are created to install SQL Server 2005 and SP2. Now you need to make that sure that you get the packages successfully to a distribution point that you'll use to get the bits during the actual task sequence steps.

While those packages are being copied to distribution points, we can get started working on the actual task sequence that will be used to install SQL Server 2005 and SP2... but you'll have to wait for me to finish Part 2 of this post to see how to do that first!

I've discovered something interesting that might make the remainder of this post moot.

When I installed WSUS for the SUP on the disconnected network and used the WSUS local internal database I could not use the download software updates wizard to obtain updates from the local Wsuscontent directory on the SUP (thus this post below). However, after writing the below post I did some additional testing and during WSUS installation for the disconnected SUP if I configured WSUS to use the SQL instance hosting the site database, and then approved required updates in the Internet-connected WSUS server (which downloaded them to the local wsuscontent dir on the Internet-connected WSUS), and then copied the wsuscontent dir to the WSUS installation on the disconnected network I COULD use the wsuscontent directory as the local source to download required updates.

I'm going to leave the remainder of this post here because it has some other useful information like running scripts to directly query the site database for information, but the bottom line is this:

From my additional testing after writing the below post, it seems that if you use the SQL instance to host the WSUS database on the disconnected SUP, you do not need to go through all of the effort below and can just download updates locally from a synchronized wsuscontent dir containing the updates as downloaded by WSUS.

[END EDIT]

Before you get to this point:

You need to have successfully synchronized your active SUP with the latest and greatest software updates metadata from an Internet-connected WSUS Server (see: this post).

Enabled the software updates client agent for the site.

Have clients that have run software updates scans and reported in updates as required.

Optionally, but recommended, created the v_RequiredUpdates view according to this post.

Now that you know which updates are required (part 1), you have to figure out how to get them on to the non-Internet connected software update point so you can deploy them. To do this, you can use a script to query directly against the site database. This example uses a .vbs script to write the required update source url properties stored in the site database for required updates to a .txt file. Then, on an an Internet-connected computer, that .txt file is used as a source file for another script that reads the .txt file and downloads all the updates listed in the file. After the updates are downloaded, they can then be copied somehow back to the non-Internet connected site and used as a local source to download software updates.

I'm running the query directly against the site database because the source url property is stored in a site database table and not a view. That makes it difficult to query using standard WMI scripts that go through the SMS Provider for information. I didn't want to change the site database any more than necessary so I figured that this would be the way to go, plus it's a great example of how to do it.

I'm not going to post the entire script here (runSQLQuery.txt is located here for download—you'll need to modify it a little bit and rename the extension from .txt to .vbs before trying to use it), but here's what it does in a nutshell:

Connects to the site database using integrated security

Runs a query to find the source url property for required updates that haven't been downloaded yet (runs the query created in part 1)

Writes the source url properties to a .txt file called SourceURLs.txt

Displays a pop-up message box to tell you how many update source urls were written to the text file.

The only part of the script that you must change is the source database and server entries in the connection object line. Otherwise, the script will run 'as is', but if you want to change the default behavior up a little, there are really only two other lines that you will need to modify (if you choose to):

Required change(s):

objCN.Open "Provider=SQLOLEDB.1;Persist Security Info=False;Integrated Security=SSPI;Initial Catalog=SMS_XYZ;Data Source=SiteServer"The default security settings will connect to the site database using integrated security. If you want to use a username & password to connect to SQL, then add in this after Persist Security Info=False: User ID=<account>;Password=<password>; and take out the Integrated Security part. You also need to change the site database name (Initial Catalog), and the site database server name (Data Source) to match your requirements.

Optional changes:

strSQL="SELECT DISTINCT dbo.v_RequiredUpdates.SourceUrl FROM dbo.v_RequiredUpdates"If you didn't create the view, you can just comment out the line about querying the view and uncomment the full SQL query. In case you missed it from part 1, here it is: (watch for word wrap, this must all be on one line when used in the script):

strOutputFile = "SourceURLs.txt"By default, the script will write the download location for required updates to a .txt file named SourceURLs.txt and that file name is referenced when using the download script. If you want to use a different text file name for some reason, then just change the strOutputFile value to whatever you want to call it. You'll have to remember to use the new file name for the download script too.

OK, all that out of the way, just double-click the .vbs and it should reward you with a bunch of required updates source urls written to a text file in the same directory that the script was run from and display a message similar to:

Note: Open SourceURLs.txt and backspace the last line so there is no empty line at the end. If you don't do that the download script still works correctly, but throws an error at the end when it sees the empty line.

Now it is time to take that text file (SourceURLs.txt), go to a computer with an Internet connection, and run script number two. The second script is the one that does all the hard work for you. It reads the source urls text file and downloads the updates into the same directory the script was run from. Just in case you wanted to test this, I've included a sample SourceURLs.txt file with three update download locations here.

This script came from a few hours of me banging my head against the wall trying to figure out how to do it properly and then realizing that the other side of the wall was literally the office of one of our talented SMS SDK writers…problem solved. The download script doesn't require any modifications at all other than some error logging that I didn't add into the script and it can be found here.

This time you need to open a command prompt and use the following command: cscript downloadUpdates.vbs SourceURLs.txt.

If all goes to plan after running the script, you should see something like the below screen shot and the folder the script was run in should now contain all of the downloaded updates:

Now you just need to somehow get that directory full of source files to the non-Internet connected site, share it out, and then go through your normal ConfigMgr software updates processes. When it comes time to deploy those updates, just select the option to download source files from a location on the local network and point the wizard to your local source files share:

Some random last thoughts about these posts that I've neglected to mention so far:

Why do we need these scripts? Because you can't just synchronize a WSUS Server and then sync that WSUS Server's downloaded update content with the WSUS Server hosting the SUP site role…well, you can, but you won't be able to download updates using the WSUS content files for distribution via ConfigMgr because the software updates download wizard won't recurse through the various update directories that the WSUS Server creates when it stores downloaded updates. Same goes for using a different SUP server's package source directory (another script on the back burner for me).

This technique will download all updates that clients have determined that they require through software updates scanning. You might not want to deploy every update that a client has found it requires so this might end up just using up hard drive space on your server with a bunch of unnecessary updates. Of course, you could just delete the original source directory contents after you create the deployment package, but the next time you run through this process those same updates will reappear as they're still required and haven't been downloaded yet. I figured it was better to have all the updates there just in case you ever ended up needing them than to have to go through this process all the time for smaller groups of updates. That being said, another option is to only download required updates that haven't been downloaded yet that exist in defined update lists. I'm working on that, but it has taken me a while to get to this point and to be honest I really need to get back to my day job J

These scripts are really more of an example and they'll work 'as is', but you might want to refine them as needed later on.

I hope you've found these posts (or at least some part of them) helpful and this technique gets your disconnected SUPs sync'd, and your clients patched!

You need to have successfully synchronized your active SUP with the latest and greatest software updates metadata and the WSUSContent directory from an Internet-connected WSUS Server (see: this post).

Enabled the software updates client agent for the site.

Have clients that have run software updates scans and reported in updates as required.

Now that you know which updates are required, you have to figure out how to get them on to the non-Internet connected software update point so you can deploy them. The first part of all of this (part 1 of this post) is to query the site database to find all the required updates that you want to download. After you get that far, you'll need to use some handy .vbs scripts to actually do all the hard work and download the updates from a remote computer with an Internet connection—that will be part 2.

Technically, you don't have to create this view, but it makes the syntax of the script to come easier with the added bonus that you can use the view to create a Web report to view more information about the required updates other than just their download location.

NOTE: If you use this view to create a Web report, don't forget to grant the webreport_approle application role the required select permissions!

Here's the query that I'm using for the view and an explanation of what I'm actually querying on. Basically, what I'm after are required updates that haven't been downloaded yet and aren't expired (we can't deploy expired updates with ConfigMgr). If you create this view, make sure that you call it v_RequiredUpdates because that's what the script in the next post will query on:

Here are some .sql files that you can use to make all of this easier. I've had to rename their file extensions from .sql to .txt to upload them, but you'll need to right-click and download them anyway because the database to use needs to be changed to your site database name. After modifying the database to use in the files, change the file extension back to .sql before running them:

If you don't really want to go into SQL to create the view, here is a little .sql that will create it the easy way (make sure you change the USE line at the top to use your site database!): Create_v_RequiredUpdates.sql. This one is pretty long so I'm not going to post the contents of it here; you can see what is in there using Notepad.exe though.

If you just want to run the query real fast to see what it's supposed to get, run this: View_v_RequiredUpdates.sql. Below are the contents of that .sql:

/*** Use this .sql to view the query results AFTER you create the v_RequiredUpdates view ***/ /*** Change the USE and FROM lines to use your site database! ***/

USE SMS_XYZ

SELECT [DatePosted]

,[BulletinID]

,[ArticleID]

,[Title]

,[SourceURL]

,[ContentLocales]

FROM [SMS_XYZ].[dbo].[v_RequiredUpdates]

Now that you've got the view returning a list of required updates, the next post will show you how to use that view to actually download them.

Because the highest level active software update point for a Configuration Manager site hierarchy must synchronize with Microsoft Update, it can be a little difficult to get this working in non-Internet connected sites. This post explains how to get the latest software updates scan metadata imported into the site database to enable software updates functionality for non-Internet connected Configuration Manager sites and site hierarchies.

This process is already documented in the Configuration Manager documentation library, but I figured that I'd blog the steps that I took as another resource for you. You should probably check out the 'official' version first: How to Synchronize Updates Using Export and Import at: http://technet.microsoft.com/en-us/library/bb680473.aspx .

To get started, you'll need to have the x86 version of WSUS 3.0 SP1 (WSUSSetup_30SP1_x86.exe) installed on a computer that has Internet access. This is because the tool used to export and import the metadata only works on the x86 version. Clients don't need to connect to this computer and it can even be a VM. We just need to get the WSUS catalog synchronized with Microsoft Update so we can transfer the scan metadata back to the SUP in the non-Internet connected site. WSUS installation is fairly straightforward so I won't go into it in much detail here. Just be sure that you install both WSUS and the administration console and configure the WSUS Server to store updates locally (we won't actually download any updates on this server, but the update EULAs need to be stored locally in the WsusContent directory so we can transfer them later).

Tip: You don't need to install WSUS 3.0 before installing SP1. Just run the SP1 install and you'll have everything you need.

For the WSUS installation that will synchronize with Microsoft Update, you'll need to install both WSUS and the administration console. For the WSUS installation that will be co-located with the non-Internet connected software update point (if it's not on the site server computer), you only need to install WSUS. The WSUS administration console bits need to be installed on the non-Internet connected site server so we can configure the WSUS settings, but that's a standard software update point prerequisite so I'm guessing you already knew that. If you didn't, the prerequisites for Configuration Manager software update point installation are located in this topic Prerequisites for Software Updates at: http://technet.microsoft.com/en-us/library/bb680712.aspx .

I'm going to break down the following steps and call the WSUS Server installation connected to the Internet the WSUS export server and the WSUS installation supporting the software update point site system for the non-Internet connected site the WSUS import server.

On the WSUS export server:

Install WSUS 3.0 SP1 (WSUS and administration console), open the administration console, click Options, and start the WSUS Server Configuration Wizard. Most of the pages are fairly straightforward, but here they are as well as some things to keep in mind while configuring the WSUS installation:

Decide if you'll participate in the Microsoft Update Improvement Program.

Choose and upstream server to synchronize updates from (you'll want to synchronize with Microsoft Updates).

Configure a proxy server if necessary.

On the Connect to Upstream Server page, click Start Connecting. This downloads the types of updates available, the products that can be updated and available languages. This is going to take a couple of minutes.

On the Choose Languages page, select the languages that you want to download updates for and click Next (it probably doesn't matter what is selected here as we won't use WSUS to download the updates anyway).

On the Choose Products page, select the products that you want to synchronize updates for with Microsoft Update. These should be the products that you want to be able to patch your clients for in the non-Internet connected site later (ie Exchange Server 2007, Forefront Client Security, Windows Server 2008, etc…).

On the Choose Classifications page, select the update classifications that you want to synchronize with Microsoft Update. Once again, these should be the classifications that you want to be able to patch your clients for in the non-Internet connected site later (ie Critical Updates, Security Updates, Updates, etc…).

On the Configure Sync Schedule page, select a sync schedule option. You can either synchronize on a schedule or manually.

On the Finished page, select the Begin initial synchronization option. Click Next and then Finish to begin synchronization. Some quick notes about this process:

Grab a Snickers® it's going to be a while before the initial synchronization completes. I found it to be somewhere between around 1.5 to 2 hours.

The WSUS database file sizes will increase during this process. The initial database files were 20.1MB and 2 MB for the SUSDB.mdf and SUSDB_log.ldf database files respectively. After synchronization, the database file sizes were 710MB and 61.9MB.

Verify the WSUS installation has completed synchronizing successfully by watching the SoftwareDistribution.log log file (%Program Files%\Update Services\LogFiles\) or you can also check the Synchronizations node of the WSUS administration console.

Next, you need to export software update metadata using the wsusutil.exe utility.

Open a command prompt and navigate to the %Program Files%\Update Services\Tools directory.

Run the following command to export the software updates scan metadata:wsusutil export <drive letter>:\export.cab <drive letter>:\export.xml. You don't need to name them export.<extension>, it's just something that I do. You can name them whatever you want, but ensure that you save the export as a .cab. I also save the log file as an .xml because it makes it easier to read later.

This takes about 15 minutes or so. In my little lab installation, the exported files were around 8MB for the export.cab and around 4MB for the export.xml. You won't see much interesting going on, but your command prompt should now display:Updates are being exported. Please do not stop this program.When it is finished, you'll see this message in the command prompt window: All updates are successfully exported.

On the WSUS import server:

After the metadata export has completed, find some way to copy the export files to WSUS installation that is going to host the software update point for the non-Internet connected site. By this point I'm assuming you already have WSUS 3.0 SP1 and a software update point site system configured for the site. If so, skip to 3, if not go to 2 J

If you're installing WSUS on a soon-to-be software update point site system computer that is not on the site server, you need to install WSUS (no admin console) on the software update point computer and the administration console on the site server computer. However, if you're installing WSUS on the site server computer, you'll need to install the full installation including the Administration Console. If you do need to install the console, do just that—install it, but don't configure it. During installation when the Console Configuration wizard starts—click Cancel. When installing WSUS, take note of these settings:

Do not synchronize from Microsoft Update and do not create WSUS reporting events.

Do not schedule synchronization (we'll do it manually).

Don't worry about the classifications and products settings (you can only configure those if you're sync'ing with Microsoft Update, so we'll handle what metadata we get from the online WSUS Server export files.

Select the languages that you want to download (probably doesn't matter because we'll have to manually download these later).

Finish the WSUS installation wizard.

Install a software update point site system role on the newly installed WSUS Server and review SUP setup logs to ensure it is installed and WSUS is configured successfully: SUPSetup.log and WSUSCtrl.log log files in the ConfigMgr logs directory.

Navigate to the Software Updates node in the Configuration Manager console. Refresh the software updates feature home page and you shouldn't see any software updates information.

Copy the WsusContent directory contents from the export server to the import server's WsusContent directory (C:\WSUS\WsusContent by default).

Import software update metadata using the wsusutil.exe utility so that software updates home page won't be so boring.

Open a command prompt and navigate to the %Program Files%\Update Services\Tools directory.

Run the following command to import the software updates scan metadata:wsusutil import <path>\export.cab <path>\import.xml. Of course, you'll need to know where you copied the .cab file that was exported from the WSUS export server at this point.

The import process takes about 15 minutes or so. You still won't see much interesting going on, but during the import process your command prompt should display the following until the import process has completed:Updates are being imported. Please do not stop this program.When it is finished, you'll see this message in the command prompt window: All updates are successfully imported.

After the import process completes, go back to the Configuration Manager console, expand Software Updates, right-click Update Repository and select Run Synchronization. Some notes about this process:

Grab another Snickers® it's going to be a while again. This is the point where the WSUS software update metadata information is being imported into the site database. To view the progress of the import process, you can watch the wsyncmgr.log log file. This log file tells you how many updates (metadata) were imported and even how long it took—this process took 3 hours and 19 minutes in my lab!

Another disk space consideration: my lab's site database was 223MB before synchronizing metadata. After synchronizing the updates that were exported from the WSUS export server (remember the 8MB export.cab file?), the site database was 891MB!

Of course, none of those updates display as required by clients until you have clients, with the software updates client agent enabled, complete the software update scan cycle, but that's another post J

Steve Rachui is at it again. This time he's explaining how to setup R2's OSD multicasting feature. It's a great post and contains some very important information that you should be aware of if you're going to implement multicasting--definately a must read.