Silent App Install Help Page
Anyone who works in enterprise IT (and with products such as Configuration Manager) needs to know how to install applications silently…without requiring user intervention. Recently I came across a web page that gives really good info on the various installation types (MSI / InstallShield / Wise / etc) and how to make them silent. It goes beyond the basics and gives background on how each of them work. The page hasn’t been updated in a while, but there is still some very good information there. This could be a good one to bookmark.
http://unattended.sourceforge.net/installers.php
Remote SQL Security Concern
I have had a few discussions over the years about whether a Configuration Manager installation should include SQL “on box” or “remote”. The answer is generally “it depends”. This blog post is not going to dig into all of the reasons why you would choose either local or remote SQL…it is designed to highlight one particular security concern with the remote SQL option. Let’s think through several of the underlying components that are necessary for remote SQL to take place along with a few very common scenarios when this is the case.
- Generally a company will choose remote SQL because they want to have a beefy SQL box that is managed by their DBA team. This SQL box will commonly house several SQL databases…not just the Configuration Manager DB. Which means that any disruption on that SQL server has an impact on much more than just Configuration Manager.
- A requirement for remote SQL with Configuration Manager is that the Configuration Manager server’s computer account must be in the local admin group on the SQL server.
- Commonly there will be a number of Configuration Manager administrators that have admin rights on the Configuration Manager server.
- Commonly there will be a number of those same Configuration Manager administrators that do NOT have admin rights on the remote SQL server.
THAT is where the problem rears it’s head. Let’s connect all of the dots…
- Joe Admin is an admin on the Configuration Manager server…but is not an admin on the SQL server.
- The Configuration Manager server’s computer account is an admin on the SQL server.
- Joe Admin has read my article on how to run a command prompt as local system. Uh oh.
- Joe Admin uses psexec to run a command prompt (or SQL Management Studio…or regedit…or services.msc…or disk management…or whatever else) as local system on the Configuration Manager server.
- Joe Admin then connects that app (running in the “user” context of the Configuration Manager server’s computer account) to the SQL server.
- Joe Admin is now able to do anything that the Configuration Manager server’s computer account has rights to do…which is full Administrator rights…ON THE SQL SERVER!!!
- That security you thought you had…well it didn’t work so well.
Is there anything to keep Joe Admin from (either accidentally or maliciously):
- Stopping services?
- Deleting files?
- Rebooting the server?
- Jacking with the registry?
- Installing (either good or bad) software?
- Copying data off of the SQL server?
- etc (I think you get the picture.)
Now…for some people that doesn’t matter. In many smaller installations the same team is managing Configuration Manager and SQL. However…if you are that small…why take on the extra complexity of the remote SQL scenario?
For others it matters big time! I’ve had conversations with customers who cringe at the very idea that some random Configuration Manager admin could possibly gain full rights to the SQL server that other business critical databases are stored on.
Business Value of Application Replacement
Who cares? That is the thought that went through my mind last night a few hours after I posted the last of my five part series on Dynamic Operating System Deployment and application replacement. Even if you don’t now, you SHOULD care. Let’s see if I can convince you…
Let me give one example of the difference that the concepts in that series made at a company. I had a client recently who was performing a company-wide Windows 7 rollout…migrating from Windows XP. This coincided with a PC replacement cycle, so this rollout was predominantly a “Computer Replace” scenario…so replacing the old XP box with a new Win7 box. After replacement, users obviously needed to be able to do their jobs on the new Win7 system…which meant that they needed some key applications that had previously been installed on their Windows XP system…but these apps had been installed on a case by case basis previously. The company has not implemented role-based application deployment at this time.
And THAT is where the problem arose. MANY of these applications are not in the core Windows 7 image for obvious reasons. (Visio, Project, Creative Suite, Oracle apps, numerous internal apps) For that matter, many of the apps that were installed in Windows XP were being replaced with a newer version in Windows 7 for application compatibility reasons. For this company it meant that when they performed the Windows 7 refresh on a location, they flew two employees to the refresh location to perform the upgrade. The PRIMARY reason that they needed to do this was so that the two employees could re-install applications on the user’s Windows 7 computer post-install on a case by case basis. This resulted in significant business problems including:
- User downtime because necessary applications weren’t installed on their new Windows 7 system.
- IT staff were pulled away from their day-to-day job for a week at a time to drive the migrations…mainly because of the need to install additional applications.
- The Windows 7 migration for the company was taking SIGNIFICANTLY longer than desired because of these limitations (both app installs and a limited number of employees to travel to numerous locations).
- Significant additional costs were associated with all of this (travel, time, delays, loss of user productivity)
Quite simply it was an unacceptable situation. Way too much wasted time and effort. That’s when they called us to see if we could help them streamline this process. I implemented the steps I outlined in posts 1, 2, 3, 4, and 5. The client saw some very significant improvements from a business value perspective…including…
- A VERY significant reduction in the number of special post-image application installations.
- Automated re-installation of required applications without the need for IT staff intervention.
- Significant reduction in user downtime as a result of the migration process.
- Consistency from an end user perspective. (i.e. My computer used to have Program X and it still does.)
- Smoother Windows 7 migrations.
- The company expects that significantly less travel will be required to perform the Windows 7 migrations.
- Cost savings…both travel related and time related.
So…should you care about making your operating system deployments dynamic and adding the application replacement functionality to the process? If cost and time savings mean anything to you, then yes you should. Don’t know about you, but I’ve got better things to do with my life than to babysit an OS deployment! :-)
OSD and the MDT Database (5 of 5)
This is the last of a five part series on utilizing the MDT integration into Configuration Manager to improve your Operating System Deployment functionality. These processes will make your OSD setup much more dynamic. The series will be:
- Assumptions and creating the MDT database
- Dynamic OSD using the MDT Database
- Application Replacement #1…this post is the reason I started the series. Modifying the RetrievePackages stored procedure.
- Application Replacement #2. Populating the PackageMapping table.
- OSD and the MDT Database…connecting all the dots from the previous four posts. Setting up a task sequence to use the MDT database.
So, up to this point in this series we have put most of the pieces in place that are necessary to allow both Dynamic operating system deployments that are driven by the MDT database as well as perform Application Replacement during both Computer Refresh and Computer Replace scenarios. Now we need to tie all of this together and make it work together.
The two remaining pieces of the puzzle are:
- Create the CustomSettings.ini File
- Set up the Task Sequence to Process the Database Settings
Application Replacement (4 of 5)
This is the fourth of a five part series on utilizing the MDT integration into Configuration Manager to improve your Operating System Deployment functionality. These processes will make your OSD setup much more dynamic. The series will be:
- Assumptions and creating the MDT database
- Dynamic OSD using the MDT Database
- Application Replacement #1…this post is the reason I started the series. Modifying the RetrievePackages stored procedure.
- Application Replacement #2. Populating the PackageMapping table.
- OSD and the MDT Database…connecting all the dots from the previous four posts. Setting up a task sequence to use the MDT database.
In the previous post we modified the SQL stored procedure to make Package Mapping work for both a Refresh and Replace scenario. However neither scenario will work until we populate the PackageMapping table in the MDT database.
Populating the PackageMapping Table
The PackageMapping table has two columns: ARPName and Packages. Each entry in the table creates a correlation between a piece of installed software (ARPName) and a Configuration Manager Package/Program (Packages).
The values in the ARPName column come from the values in the Uninstall registry key. (HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall OR HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall). MSI installs will be GUIDs. Non-MSI installs will be other names…not necessarily the DisplayName from Add/Remove Programs. The value in this field corresponds with the SMS_G_System_ADD_REMOVE_PROGRAMS.ProdID field in the Configuration Manager database which is gathered by Hardware Inventory.
The Packages column contains the PackageID and Program Name for a Configuration Manager Package. The proper format for this column is: “XYZ00000:Program Name” where XYZ00000 is the Package ID, and “Program Name” is the exact name of the Configuration Manager Program Name in the package. Of particular importance, the values in the Packages column are case sensitive.
We need to do four things in order to populate this table:
- Obtain the ARPNames that we care about
- Obtain the Package:Program combinations that we will correlate to the ARPNames
- Correlate which ARPNames should install which Package:Program.
- Add the ARPName = Package:Program to the table
Application Replacement (3 of 5)
This is the third of a five part series on utilizing the MDT integration into Configuration Manager to improve your Operating System Deployment functionality. These processes will make your OSD setup much more dynamic. The series will be:
- Assumptions and creating the MDT database
- Dynamic OSD using the MDT Database
- Application Replacement #1…this post is the reason I started the series. Modifying the RetrievePackages stored procedure.
- Application Replacement #2. Populating the PackageMapping table.
- OSD and the MDT Database…connecting all the dots from the previous four posts. Setting up a task sequence to use the MDT database.
In the first post in this series, we set up the MDT database in our already functional Configuration Manager environment. The second post showed how to populate the MDT database in order to make our OSD process much more dynamic. This post will show the Application Replacement functionality.
Background:
For a while now MDT has included the ability to dynamically replace applications during a computer refresh scenario. (i.e. if the computer being reimaged has Visio installed, dynamically install Visio as part of the reimage) In a MDT only scenario, this is done with the UDI wizard via the Application Discovery pre-flight check. This can also be done using the integration with Configuration Manager…basing the software reinstall on the Configuration Manager inventory. While this functionality has been there for a while, I have found two pieces of it lacking:
- How to do this is buried in documentation that makes it a bit challenging to implement. (The MDT document that talks about this is a 497 page Word doc…good luck.)
- The process only works for a computer refresh scenario. It does not work in a computer replace situation…which is fairly common with my clients. They are not upgrading older Windows XP systems to Windows 7…they are replacing the computer. But they still need the user to have access to their current applications after the upgrade.
That is the reason for this blog post. First I want to show how to do this without having to dig through a huge doc. Second, I want to show how to modify this feature to allow for doing application replacement in both the Computer Refresh and the Computer Replace OSD scenarios.
Dynamic OSD using the MDT Database (2 of 5)
This is the second of a five part series on utilizing the MDT integration into Configuration Manager to improve your Operating System Deployment functionality. These processes will make your OSD setup much more dynamic. The series will be:
- Assumptions and creating the MDT database
- Dynamic OSD using the MDT Database
- Application Replacement #1…this post is the reason I started the series. Deals with necessary modifications to the RetrievePackages stored procedure.
- Application Replacement #2. Populating the PackageMapping table.
- OSD and the MDT Database…connecting all the dots from the previous four posts. Setting up a task sequence to use the MDT database.
In the first post in this series, we set up the MDT database in our already functional Configuration Manager environment. (Check the assumptions section of the previous post.) Now let’s look at populating the database with information that will make our OSD process much more dynamic.
Populate the MDT Database:
The MDT database can be used to customize the deployment of systems. Customization can be based on Location, Make/Model, Roles, or tied to a specific Computer via Asset Tag or MAC address. The customizations available are numerous and include software installation as well as various AD and OS settings.
Configure Locations
Locations in the MDT database are set up based on Default Gateway.
- Select Location, then click “New”. Read more »
Configuration Manager and the MDT Database (1 of 5)
This is the first of a five part series on utilizing the MDT integration into Configuration Manager to improve your Operating System Deployment functionality. These processes will make your OSD setup much more dynamic. The series will be:
- Assumptions and creating the MDT database
- Dynamic OSD using the MDT Database
- Application Replacement…this post is the reason I started the series. This will discuss configuring the application replacement functionality (also referred to as package mapping)…one of the more powerful components of OSD once it is working correctly! In a nutshell, it is a process for dynamically replacing applications during a computer refresh or replace scenario. For example, if a computer has Visio installed and I re-image it…ensure that Visio is re-installed. Or…if Acrobat 6, 7, 8 or 9 is installed…replace it with Acrobat X. VERY nice! This post will detail the necessary modifications that must be made to the RetrievePackages stored procedure in order for this to work for both a Refresh and Replace scenario.
- Application Replacement #2. Populating the PackageMapping table.
- OSD and the MDT Database…connecting all the dots from the previous four posts. Setting up a task sequence to use the MDT database.
While the end goal of this series is to show you how to use the MDT database to perform dynamic application replacement in your Configuration Manager task sequence, there is a lot that must be put into place before we get there. First let’s deal with a few assumptions that I am making.
Assumptions:
- Configuration Manager 2007 is installed and functional
- OSD is functioning at a basic level…image is imported and can be deployed via a standard deployment task sequence
- MDT 2010 Update 1 is installed on the site server
- “Configure Configuration Manager Integration” has been run on the site server
- An MDT Task sequence has been created and the wizard has built packages for:
- USMT
- MDT Toolkit
- Custom Settings
- A boot image has been created using the “Create Microsoft Deployment Boot Image” wizard. During the wizard, ADO support must be added to the boot image. ADO support is required to be able to query a database from Windows PE. Any necessary Mass Storage and Wired NIC drivers should also be added to the boot image.
Creating the MDT Database:
- Log on to the server where MDT is installed with an account that has rights to create a database on the SQL server.
- Open the Deployment Workbench
- Right click “Deployment Shares” and choose to create a New Deployment Share
- Walk through the rest of the wizard. Take note of the share name (the default share name is “DeploymentShare$”) as we will refer to that later. There is no need to populate the deployment share like you would need to do if just using MDT. Uncheck all of the checkboxes in the wizard (image capture, admin password, and product key).
- Expand Deployment Shares | MDT Deployment Share | Advanced Configuration | Database
- Right click Database, select New Database. Follow the New DB Wizard
- Enter the SQL server that will host the DB. Choose “Named Pipes” for the Network Library. I have seen others who have commented that TCP/IP can be problematic. These were mostly old posts, so it may not be an issue any more. Whichever is used, be sure it is enabled on the SQL server.
- Choose to create a new database. Give it a name that makes sense. (e.g. MDTdb)
- On the SQL Share screen, choose any share that exists on the SQL server. This is only used for establishing that the credentials can work. It can be any share. In a single server scenario where the MDT Deployment share is on the server, you can use DeploymentShare$ that was created when you created the Deployment Share in step #3 above. If a special share is created just for this purpose, then a file should be created in the share to indicate its purpose to protect against accidental deletion because someone thinks it is not being used.
- Continue through the wizard to finish. The new DB connection will appear in the Deployment Workbench.
Summary:
This post walked through the background requirements and the initial creation of the MDT database…the necessary pre-reqs for the Application Replacement / Package Mapping functionality to work. The next post in the series will show you how to populate the MDT database to set the stage for customizing your OSD deployments.
Windows 7 Customizations
Over the last few years as a consultant I’ve had numerous engagements where clients wanted to customize the look/feel/settings in Windows 7. Different clients had different requirements around which customizations, whether it was permanent or a preference, etc. Below is a list of several customizations that I have helped clients perform. Many of these are found at various locations in forums, blog posts and Microsoft documentation. My goal is to gather these into one location so that it is easier for some of the more common (and for that matter some of the more obscure) customizations to be found. These are in no particular order. I will update this list from time to time. If you have any favorite customizations that you’d like to pass on, email me on my contact form and I’ll add them in. This post is REALLY long, so click the “Read More” link if you want to see the customizations.
ZTItatoo.wsf–Error 9601: DNS Zone Does Not Exist
Recently I ran into an issue where a task sequence was failing on the Tattoo step of an MDT integrated task sequence. The error that shows up in the Status Message viewer is:
The task sequence execution engine failed executing the action (Tattoo) in the group (Execute Task Sequence) with error code 9601.
The operating system reported error 9601: DNS zone does not exist.
Now…I know that the real error has nothing to do with DNZ zone. That error code was generated by the ZTItatoo.wsf script. Taking a quick look through the MDT documentation (gotta love the search function in Word) for that error code shows what the script thinks is going on…
ERROR – ZTITatoo state restore task should be running in the full OS; aborting.
So…at least I’m on the right track…but I’m in the full OS already…why the bogus error? Looking through the script shows that the script is the value of an environment variable:
If oEnvironment.Item(“OSVersion”) = “WinPE” then
oLogging.ReportFailure “ERROR – ZTITatoo state restore task should be running in the full OS, aborting.”, 9601
End If
The reason I got this error is that I had stripped out a bunch of tasks from the default MDT task sequence…including the Gather task that runs just before the Tatoo task. The Gather tasks sets a ton of variables based on the current state of the system…including the “OSVersion” variable. The only time the Gather task had run in my task sequence was at the very beginning…when it was still in PE. Adding that step back in fixed the issue.
Error Code 31 During Build & Capture Task Sequence
I’ve seen this a few times during Operating System Deployment engagements at clients. During a Build and Capture task sequence the TS will fail with a 80004005 exit code. Looking at the SMSTS log or in the status messages for the advertisement will show messages similar to:
Windows Setup completed with exit code 31
Exiting with code 0×80004005
Windows setup failed, code 31. The operating system reported error 2147500037: Unspecified error
Lovely. What the heck does that mean? Since we all know how helpful 80004005 is. :-)
In looking at the logs located in x:\windows\temp\smstslog\windowssetuplogs (I can’t remember which log file.) I found reference to setup not being able to import a critical driver. Now we are getting somewhere…which driver is it? A blasted Alps Touchpad driver. Not sure about you, but that does not rise to the level of “critical” to me during a completely hands off process like a task sequence.
Basically I left the default “Auto Apply Drivers” step in the B&C Task Sequence. The client had previously imported a ton of drivers…including the “critical” Alps Touchpad driver. Simply disabling the Auto Apply Drivers step in the TS let the task sequence continue. Since the B&C only runs on a virtual machine I don’t need that step anyway.
UDI Application Weirdness
One of the really cool aspects of MDT 2010 Update 1 is the integration of what was formerly known as Modena…now named “User Driven Installation”. This provides a very slick looking wizard that can pop up at the beginning of a task sequence to allow for customization of the OSD process. There is a lot of functionality there around computer naming, domain/workgroup joining, OU selection, adding a user to the local admin group, language selection, and others. The feature that most of my clients are interested in however is the ability to customize application deployment for apps that are not in the image (Project, Visio, Acrobat, etc).
There has been one aspect of this that has caused issues on multiple occasions that I figured was worthy of a detailed blog post. The issue comes up if you use the default configuration file (UDIWizard_Config.xml) as your starting point when you run through the UDI Wizard Designer. After customizing the applications section, you still see the default applications screen when the wizard runs…either using the “Preview OSDWizard” command or running it in a Task Sequence. What you see is:
Digging into that default XML file shows us why this issue comes up. First you will notice that one of the “Preflight” checks that is performed is the “Application Discovery” check.
This allows you to configure app replacement in a re-image scenario (i.e. if Office 2007 is installed, install Office 2010…if Acrobat 9 is installed, install Acrobat X…if EditPlus is installed, install Notepad++). This really is a cool feature. However…if you haven’t configured this aspect it’s not necessary to run the check, so you can just delete it. However…deleting that from the Preflight does not clean up the other references to it in the XML file. If you edit the XML directly you will notice the following lines down in the Application configuration section. Note that there is still a reference to the AppDiscovery preflight check.
<Page Name="ApplicationPage" Behavior="enabled">
<Applications Link.Uri="preflight\AppDiscovery\AppDiscoveryresult.xml" TsAppBaseVariable="PACKAGES" RootDisplayName="Applications">
Removing the reference in the “Link.Uri” attribute resolves the issue. That section should look like:
<Page Name="ApplicationPage" Behavior="enabled">
<Applications Link.Uri="" TsAppBaseVariable="PACKAGES" RootDisplayName="Applications">
After doing so, you will see the customized application section that you configured using the wizard:
PXE Booting and IP Helper-Address Resources
I commonly work with clients who want to use PXE as the method for starting the Operating System Deployment process. In practically all instances the ConfigMgr server (and hence the PXE Service Point) and the clients are not on the same subnet. By default the PXE UDP packet will not be forwarded by the router…it will just drop it. As a result there are two methods for getting PXE to work across subnets…the IP Helper-Address and setting DHCP options.
Let me first address the DHCP Options scenario. First, this option is officially unsupported by Microsoft for getting PXE to work (per this blog post). It can work, but it may not be reliable and consistent. The DHCP options to set are a combination of 60, 66 and 67 depending on the scenario…in particular depending on whether the PXE server is on the same box as the DHCP server. The blog post linked above describes the options.
Below are a few resources that I have found helpful in understanding what the IP Helper-Address is, why you would set it, and defending the decision with the network team (which nearly ALWAYS happens). I will update this list as I find others. If
Troubleshooting the PXE Service Point and WDS in Configuration Manager 2007
Cisco IP Addressing and Services Commands
Cisco Support Forum: DHCP and PXE Question (see the response in this thread from Robert Taylor)
Trinity Explains The IP Helper-Address Command
Checklist for getting PXE to work in ConfigMgr
PXE Service Point causes the Windows Deployment Services Server service to crash and hang
ConfigMgr Version Numbers
I posted on this once before but realized last week that an update was in order. First, there were a few version numbers missing from my original post. Second…I only dealt with part of the question. When looking at version numbers for ConfigMgr, there are typically two items that someone might be referring to…the version of ConfigMgr installed on the site server or the version of the ConfigMgr client installed on the clients. My previous post mostly dealt with the site server question. This one will be an update to the original along with dealing with the client version numbers as well. BTW…I’ve seen posts scattered around the web that deal with this to varying degrees…I’m trying to gather all of the info out there into one place…something I haven’t been able to find.
ConfigMgr Site Server version numbers:
|
ConfigMgr RTM |
4.00.5931.0000 |
|
ConfigMgr SP1 |
4.00.6221.1000 “R2 installed: No” (See the screenshot below.) |
|
ConfigMgr SP1 R2 |
4.00.6221.1000 “R2 installed: Yes” |
|
ConfigMgr SP2 (RC) |
4.00.6468.2001 |
|
ConfigMgr SP2 (RTM) |
4.00.6487.2000 |
|
ConfigMgr SP2 R3 |
4.00.6487.2000 “R3 installed: Yes” |
Note: If an International Client Pack is installed it will change the second digit of the last section. ICP1 makes that digit a “4” while ICP2 makes it a “7”, so the SP1 version would be 4.00.6221.1700 with ICP2 installed.
ConfigMgr client version numbers:
|
ConfigMgr RTM |
4.00.5931.0000 |
|
ConfigMgr SP1 |
4.00.6221.1000 |
|
ConfigMgr SP1 (with KB977203) |
4.00.6221.1193 |
|
ConfigMgr SP2 (Beta) |
4.00.6425.2000 |
|
ConfigMgr SP2 (RC) |
4.00.6468.2001 |
|
ConfigMgr SP2 (RTM) |
4.00.6487.2000 |
|
ConfigMgr SP2 (with KB977203) |
4.00.6487.2111 |
|
ConfigMgr SP2 (with KB977384 beta) |
4.00.6487.2119 |
|
ConfigMgr SP2 (with KB977384 beta) |
4.00.6487.2125 |
|
ConfigMgr SP2 (with KB977384) |
4.00.6487.2157 |
|
ConfigMgr SP2 (with KB2509007) |
4.00.6487.2188 |
Note: R2 and R3 do not change the client version number.
Task Sequence Hangs During Updates–Fixed?
I’ve seen this many times and just found out that it has potentially been fixed. Situation is that during a task sequence, the whole TS will hang at the apply updates step. The hang occurs when the “Download xx of xx updates” shows.
In theory this has finally been fixed! I haven’t had the opportunity to test it, but it certainly looks promising! Check out this KB for the fix:
http://support.microsoft.com/kb/2509007/en-US
Thanks to Jeff Boehlke at Campus Crusade for Christ for alerting me to this. Jeff is the guy I trained to be my replacement when I left CCC a few years ago.
System Center Roadmap 2011
This was one of the slides from the second keynote at MMS last week. This is a slide they show every year to highlight what is coming in the System Center arena over the coming year. What is really exciting about this one is that a new version is coming for everything in the System Center family this calendar year. This is a lot of very exciting changes coming. This does come with a caution though…there’s a lot of work to be done ahead of time to be prepared for the launches!
Anti Malware–the landscape just changed
HUGE announcement at MMS just now. Forefront Endpoint Protection 2010 is now part of the Microsoft Core CAL. This means that all the customers who have a Core CAL already…which many who own ConfigMgr have it licensed via the Core CAL…ALREADY have the licensing in place for FEP…they already own it. If you have a Core CAL…it eliminates the need to purchase a separate AV license. You can just use FEP…which is managed via the ConfigMgr console…which eliminates a separate management infrastructure for malware…you simply manage it all via ConfigMgr.
This will likely have a big impact on AV vendors. I can hear clients asking the question now…”I already have FEP licensed via the Core CAL…and I can manage it with ConfigMgr which I already have deployed. Why should I renew my AV licensing with ______________?”
This is huge. It should be very interesting to see the full impact of this announcement over the next year or so.
ConfigMgr 2012 Beta 2–Tomorrow?
During the State of the Union session at MMS this morning, there may have been a slip of the tongue by one of the presenters. They had been saying that Beta 2 for ConfigMgr is “very soon”…then at one point I’m almost positive that I heard a slip of the tongue stating “when you download it tomorrow”.
By no means definitive, and could have just been a slip that is not based in reality…or it could have been a slip to an announcement that was being held for tomorrow.
Logging Task Sequence Variables
How many times have you worked with Task Sequence variables via either a script or CustomSettings.ini and really needed to know what the value of a particular variable was at a specific point in the task sequence? I really need to know what that variable is so that I can use it appropriately for some of the customization I have set around the variables.
One of the most helpful posts I have come across in the last several months was written by Daniel Oxley on the Deployment Guys blog. It was a post from a while ago that essentially shows how to easily log the variables. You simply download the VBS from his post and put it in the scripts folder of your MDT package. Then just call the script via a “Run command line” task. It dumps a log to the standard logs folder on the client with Variable/value for every variable that is currently in use. One cool thing is that it names the file based on date/time stamp, so you can run it multiple times in the same task sequence to see how the variables change as it walks through the process. I found it to be immensely helpful when working with some of the other MDT scripts that are customized heavily on variables.
Check out Daniel’s post and download the script here.
Computer Association Script
Fairly recently I was talking with someone who was in the midst of an XP to Windows 7 migration. They were replacing groups of computers and using a ConfigMgr task sequence to install Windows 7 on the new computers…with the USMT integration migrating the user state. Now…before that can be done, there are a few things that have to be set up:
- Create a Computer Association between the old computer and the new computer
- Add the old computer to a collection that will run a task sequence to capture the user state
- Add the new computer to a collection that will install Windows 7 and restore the user state
The guy I talked with was having a very slow time manually clicking through the ConfigMgr GUI to create these Computer Associations one by one. That is an awful lot of clicks and it was obviously slowing down his ability to move the migrations along at the speed he wished.
So…I did a little internet scavenging of scripts and put them together inside a different framework. I freely admit that my main contribution to this was pulling key components out of the other scripts and putting them into a framework that worked well for this purpose. The end result is that the task that was taking several hours for him to do by hand is now accomplished in a few seconds.
First there was a script that I found referenced by several people that was originally written by a guy named Mark Nunn. His website is now dead, but I found where his “Add to Collection” script was available on myITforum.com. From this I mainly pulled the command for adding to a collection along with how to equate a computer name to the SMS ResourceID.
Second was an excellent post by Donnie Taylor. His script will create the computer association one at a time via command line arguments. It does require that the command line argument be the SMS Resource ID of the computers. His script showed the command line for creating the computer association along with having a basic logging function.
I took those two and put logic around them to create a script that will read computer names from a CSV file, query ConfigMgr to find the SMS ResourceID, then create the association and add each computer to the appropriate collection. The list.csv file expects the first column to be the computer names of the “old” computers and the second column to the the “new” computers. The script does expect a command line argument of “import” before it will do anything. Read through it carefully…you will need to set the name of your server, the path to the CSV and the path to the log file, along with setting the Collection IDs of the Capture and Restore collections that the computers will be added to.
There are definite limitations to the script. If a computer name is in ConfigMgr more than once…I honestly don’t know what it will do. I think it will grab the first one that it finds, but I don’t know for sure. I’m sure there are others, but that is a glaring one. Feel free to download and use…but as always…use at your own risk…the script is free…you get what you pay for! You can download it from my SkyDrive.
-
Recent Visitors
Subscribe
-
Recent Comments
-
