Posts Tagged ‘Configuration Manager 2007’

I’ve been asked recently to document how you can change registry hives contained within a WIM file. This could be used either to make changes to a user account (such as the registry of the default user) or to edit the system registry settings.

The basic process for this is actually very simple, all we need to do is mount our WIM file. Once mounted, we can use the reg command to load the hive into the live system’s registry, and make the required changes. Finally, we need to unload the registry hive and then commit the changes back to the WIM.

Obviously access to DISM is a requirement for this operation. This can be located in the Windows Automated installation Kit.

Note : If you want to know where I got the Software registry hive location from, you can find HKey_Local_Machine registry hives in the C:\Windows\System32\Config folder. The hives are named as they appear in Regedit.

Once DISM reports that the image has been mounted successfully, you need to mount the registry. I’m going to mount the wim’s HKLM\Software hive in this example. You’ll notice the root of my reg path below is the folder I mounted the WIM into, given in the previous command. Type

If you now open RegEdit you will now see under HKey_Local_Machine\WimRegistry your registry hive. You are now free to make your required changes.

Once you are finished, exit Regedit. We now need to unmount the registry hive, which can be accomplished by typing

reg unload HKLM\WimRegistry

Now we need to unmount your wim image and commit the changes back into the .wim file. To do this, type in

dism /unmount-wim /mountdir:C:\AIKMount /commit

And once DISM has unmounted the image, you’re done! If you decided not to keep the changes you made (or didn’t make any and were just poking around in the reg) you would use the /discard switch instead of /commit

The Deployment Guys have a great post on persisting packages onto a machine during task sequencing so that you don’t have to repeatedly download them during the task sequence (link to follow below).

I often find that task sequences contain several custom scripts and files, stored in one or more packages that you repeatedly access. Persisting those files on the machine would save you downloading that package each time you want to access one of those files. If you are replicating the Custom Status Backgrounds from MDT 2010 this is very useful as downloading all those bitmaps repeatedly is a bit of a waste of time.

The Deployment Guys have come up with a nice script that can do this for you, however it does have a couple of (minor) limitations..

It requires the script to be inside any package you may want to persist

It requires the ztiUtility.vbs script from the MDT 2010 package to also be in each package you want to prestage

You can’t control the name of the folder that is created.

As noted in the blog post, you can simply use xcopy in a Run Command Line step to achieve a similar effect. This is nice and simple and doesn’t require you to seed packages with scripts that aren’t required for their functions. Below I’ll walk you through setting this up.

Persisting Packages

Add a Run Command Line step at the point in the Task Sequence that you want to persist your package(s). Generally you will either want to do this after you’ve handled your Disk Partition and Format steps (or repeat the steps after that point).

Change the Name of your new step to something meaningful like “Persist Package x”

Set the command of the package to xcopy *.* %_SMSTSMDataPath%\FolderName /s /e /h /y /c /I Noting the name of the folder that you are storing these files in. There is nothing of course to stop you from persisting multiple packages into the same folder.

Tick the Packages tick box, and select the package that you want to persist.

Running Persisted Packages

Add a Run Command Line step into your Task Sequence where you wish to access your package. Change the name to something meaningful.

Set your command line up as per normal.

Place %_SMSTSMDataPath%\FolderNameinto the Start in box. This will run your command as if it was from the packages folder.

And your done! I tend to place my persist tasks in their own group near the start of the task sequence (either the script or the method above) and then simply copy the group and paste it after my partition step to replace the files. Obviously if you don’t need any packages till after you format then you can just create the group after the partition step in the first place.

If you want to get fancy, you can use scripts / WMI Queries and set the first group up not to persist files if a format is required or no partition exists, but that’s a topic for another post..

One of the most useful features of WIM technology is the ability to stage multiple images within a single wim file and let the single instancing technology of the format save you an awful lot of space. This can be important when you are trying to reduce the amount of duplicated space in an SCCM hierarchy.

I recently combined 6 legacy Windows XP thick images that were almost identical (differing HAL types & image architectures, for the most part) and managed to save 30GB of space on each site server in the environment. Combined with the space saved on Distribution points this accounts for near 420GB across the environment!

The procedure is remarkably easy, but first a couple of tips to help you get the most out of this technique :

Firstly, because the only way to shrink a wim file is to export all of the images out of it into a new file, take a copy of your WIMs before you start this process. If you combine two images (or even worse, the last of many..) and find that the resulting file is too large to realistically image from, you won’t want to go through the “shrink” procedure to undo the last image appended.

Try and combine images with the same OS Codebase into one wim. While there is nothing to stop you placing XP and Windows 7 images in the same wim, there will be significant differences between the two and you won’t achieve much of a space saving unless your images are quite thick.

Placing images that are around the same patch level will also help keep the wim file size low. A year’s worth of Software updates can have a remarkable effect on the size of an image!

If you store installation folders such as the i386 folder in your images, update the images so that they all have the same version.

Right, enough waffling, on with the guide!

1. Copy your wim files to a system with the Windows Automated Installation Kit installed and start the Deployment Tools Command prompt.
2. If you want to cleanup or update the images before combining them, use DISM to mount each wim and service it (using the below command). Otherwise, skip to step 3.

Once you’ve made your changes, run the below command to commit your changes and unmount your wim

DISM.exe /Unmount-Wim /MountDir:C:\test\offline /commit

3. Once you are ready to combine your images, pick one of your wim’s to be the base wim that the other images will be added to. If you carried out changes in Step 2, you will generally want to pick the wim that had the least modifications. This is because no data is actually ever removed from a wim file, only the metadata that associates the file with the image. When we run the export command any deleted data is not exported and effectively a “clean” wim is generated. As such you want to add heavily modified images to wims that have had very few / no changes, as this will keep your final wim’s size down to a minimum. So, once you have decided, rename your base wim to something descriptive (WinXPCombined.wim, for example) and then run the below command

The <ImageName> argument is a unique name for the image inside the wim file. If you want to modify the name of the image that already existed inside the wim, you can Use Imagex’s /info option to change it :

imagex /info d:\imaging\WinXPCombined.wim <imageindex> “New Name”

4. Once the export is finished, and you are happy with wim’s size, repeat the above step until all of your images are in the wim! You’ll note that the export function will only move data that isn’t already inside the wim, so the procedure can be extremely quick or rather lengthy..

Finally, I would recommend that you test your combined wim file and make sure that all of the images have been successfully exported and appended into the final wim before you delete your originals…

I’ve recently been scheduling various different reports for different users in SCCM 2007 R3 using the SQL Services reporting role. However, due to a limitation with SQL Reporting services many of the SCCM reports have fields that are optional in the traditional reports but become mandatory in SRS reports. As an example, the Software Updates A Compliance 6 – Specific Computer report now requires you to specify both the update vendor and category. This means that you often have to run the report several times to view the status of all catalogued updates.

You can however easily modify the report so that it will display updates from all vendors and/or update categories. First we need to add a static entry to the calculated dataset to represent no filtering (or in this case, all entries). Then we need to modify the final displayed dataset to match the new entry to all items instead of only those with the matching attribute.

Open the SCCM Console, browse to the Reporting node, and under the Reporting Services entry select your report (in this case, Compliance 6 – Specific Computer).

Right click the report and select “Properties”, then click on the Dataset tab.

Click on the “Report Parameters” button.

Note down the Dataset that is used by the parameter you wish to modify. Click on OK once you are done.

In the “Dataset Name” dropdown, select the dataset that is linked to your parameter.

Click the “Edit Command Text” button to modify the dataset.

What we need to do now is specify a UNION between the data queried from the database, and any additional values we want to add. In this case, i’m going to add “All” as an option for the Update Vendor. Below is the dataset before modification :

begin
if (@filterwildcard = '')
select distinct CategoryInstanceName as Vendor0 from v_CategoryInfo where CategoryTypeName='Company' order by CategoryInstanceName
else
select distinct CategoryInstanceName as Vendor0 from v_CategoryInfo where CategoryTypeName='Company' and CategoryInstanceName like @filterwildcard
order by CategoryInstanceName
end

And now after..

begin
if (@filterwildcard = '')
select distinct CategoryInstanceName as Vendor0 from v_CategoryInfo where CategoryTypeName='Company' union select 'All' order by CategoryInstanceName
else
select distinct CategoryInstanceName as Vendor0 from v_CategoryInfo where CategoryTypeName='Company' and CategoryInstanceName like @filterwildcard
order by CategoryInstanceName
end

As you can see i’ve inserted a Union after the first Select – Where clause. This will add “All” to the list of values returned by the first select statement. I don’t need to add this to the query in the Else block because this is the query used when you use a wildcard to select a value before running the report.

Click on Ok to finish editing that dataset, and then select the dataset that is going to be displayed as the report. This will be the dataset which has the “Display Dataset on Report” tickbox ticked. Click on “Edit Command Text”.

Scroll Down to the WHERE clause in the report, and find the line that checks the value of your parameter against each entry in the database. In this example, this is the @Vendor parameter, which is checked in the following line :

and (@Vendor = '' or catinfo.CategoryInstanceName = @Vendor)

And then modify it so that every item will match if the @Vendor parameter equals our new value, ‘All’

Make the same changes for any other parameters you wish to modify (@UpdateClass, for example) and then click on Ok.

Finally, click OK again to save the changes to your report.

You should now find when you run the report, that the “All” entry will appear in your Vendor list, and when selected, updates from every vendor are shown in the report! You can easily perform this same operation on other reports if you wish to, just make sure that the parameters you are modifying are not actually required for the report. Generally, any parameter that’s used simply to reduce the results returned can be modified in this way.

Had a strange little Quirk with SCCM today that after a little bit of searching I found the answer for..

Scenario – Windows 2003 servers with optional (not scheduled / mandatory) software update deployments targeted at them. When logging into the system using RDP the “Availible Software Updates” notification was not displaying, even though checking the Logs and reports in the SCCM console showed that the box was aware it had updates approved that it required.

It seems after examining the various logs on the client that the Config manager agent was not treating the system as having anyone logged into it (not entries for my logon in execmgr). As the deployment isn’t mandatory it can only be triggered when a user is logged on, and as such the notification wasn’t being shown. I suspect this is Server 2003 behaviour as i’ve logged onto 2008 boxes using RDP several times and seen the icon displayed perfectly fine.

I logged onto the server using the /admin session and lo and behold, up popped the notification, and I could see the following entries in execmgr

A User has Logged on

The logged on user is Domain.Name\mlong

So if you encounter this as well, either log onto the machine locally (or if its a VM through it’s hypervisor manager, vSphere / HyperV etc) or use the following command line..