Sorry for the delay on this everyone. Here is the Q&A from my recent webcast.
Answers are from the following people:
Chris Nackers = CN
Ron Crumbaker = RC
Q: what’s the size of a standard boot image size? (145-180 MB)?
RC: 142MB out of the box‑
CN: 32-bit – 120MB, ConfigMgr base 132MB
64-bit 141MB, ConfigMgr base 153MB
Q: So, for boot images…why not just use one 64bit image instead of using a 32 bit?
CN: 64-bit only supports the deployment of 64-bit OS’s, 32-bit will support the deployment of both 32-bit and 64-bit OS’s
Q: I have a Dell I deployed via OSD that has an ATI display adapter. It ended up with the Intel Integrated Graphics Adapter applications (igfxtray.exe, hkcmd.exe, igfxpers.exe) listed in startup in msconfig though it’s using the ATI driver- seen this happen?
CN: Hard to answer without seeing how the TS is configured, off the top of my head, I could see a bad driver being injected via PNP, or if you had a driver package, it injected incorrect drivers as we will inject everything in the driver package. Or another possible issue is the result of a program/application being installed during the Task Sequence that caused the issue.
Q: Can the application mapping also automatically add the workstation to the SCCM Collection for the application?
CN: None of the methods I covered (MDT/UDI) have a mechanism to do this.
Q: In the ideal scenario obviously the smaller boot image the better but what would he consider a reasonable boot image size for a 20 model environment?
RC: You just don’t want it to be 500MB if you don’t need the drivers. Keep it as small as possible to get the right drivers‑
RC: For 20 Greatly different models, then you might be around 150MB or so‑
CN: I would expect somewhere in the neighborhood of 3-5 drivers added to the boot image to support 2-3 vendors and approximately 20 models.
Q: Mine is 137MB and I don’t know if its worth the trouble to change to save 2 seconds
RC: That’s a good size‑
CN: Yup, it’s a good size already, so unless you have needless added drivers I wouldn’t worry about it too much. Again part of the reason for testing drives is so that you don’t have drivers injected that you don’t need.
Q: Do you know of a good driver that works for broadcom 57xx netxtreme cards during OSD OS installer package?
(I pinged Johan for this one because I knew he would know it off the top of his head)
Johan Arwidmark: For HP servers with the broadcom netextreme I use this driver for WinPE: cp013481, and this driver for Windows: cp014607
Q: Does application mapping support wild cards for the display name?
Q: What is the best way to handle the "odd ball" application that very few people use once in a blue moon. Right now we struggle determining whether to load it by hand or make a package and do all that jazz that goes with it.
RC: I personally prefer all software to come from Configmgr, that way you don’t get stuck needing to quickly getting it deployed. Plus it is reproducible.
CN: Agreed, if you have everything else already packaged, then I would spend the time getting the odd-balls packaged as well. If you still have a large list of applications that need to be packaged, then I would consider the odd-ball to be a lowering priority. Or you can take the approach of deal with it as it comes along, you have to start somewhere on getting things managed and imported into ConfigMgr.
Q: Does User Device Affinity and Applications deployed to users bring some different things to the table now?
CN: That could be a long answer if we really got into it. The short answer is for the methods we talked about in the webcast, MDT application mapping and UDI application mapping, UDA doesn’t really play a part since those mappings are done on a machine basis. UDA is supported by a ConfigMgr 2012 Task Sequence though, but the mapping methods aren’t hooked into UDA at all.
Q: How do you keep your reference wim image current with security patches?
RC: Offline servicing is AMAZING!‑
CN: If you are using ConfigMgr 2012, then offline servicing is your best friend. If you are not on ConfigMgr 2012, then we would hope you have a build and capture task sequence, so it’s still and automated process and you just need to spin off another image while you go to lunch.
Q: Chris, to deploy (select) an app in UDI with CM did you say you must have a deployment for that application existing already?
CN: In order to add an Application to the UDI wizard, it must be deployed to the collection you have configured in the UDI Wizard Designer.
Q: when we PXE boot we get TFTP access violation error. do we need to set up TFTP on same server? we have TFTP set up on another server.
CN: Here is by far the best troubleshooting guide I’ve seen for ConfigMgr PXE issues: TechNet Blog – Troubleshooting PXE
Q: Thanks so much guys. I did get to clean up our boot image based on some of the things you pointed out. someone had even added a few wireless drivers at some point to our image. LOL. Now our small boot image is even smaller. Thanks again.
CN: J Yeah I don’t think you’ll need wireless drivers, but you are not alone, I’ve seen that a few times before!
One of the questions in my recent SCCM Guru webcast asked if it was possible to use a wildcard in the ARPName table for the mappings. I was pretty sure I had done it in the past but couldn’t find my notes on it.
In order for a wildcard to work in the table, we need to update the query in the stored procedure.
The default query looks like this: (ProductID0 was changed to DisplayName0 like I talked about in my webcast)
SELECT * FROM PackageMapping
WHERE ARPName IN
SELECT DisplayName0 FROM CM_DB.dbo.v_GS_ADD_REMOVE_PROGRAMS a, CM_DB.dbo.v_GS_NETWORK_ADAPTER n
WHERE a.ResourceID = n.ResourceID AND
MACAddress0 = @MacAddress
In order to use a wildcard in the mapping table, we need to modify the query to the following:
SELECT * FROM PackageMapping
FROM CM_DB.dbo.v_GS_ADD_REMOVE_PROGRAMS a
INNER JOIN CM_DB.dbo.v_GS_NETWORK_ADAPTER n ON a.ResourceID = n.ResourceID
WHERE MACAddress0 = @MacAddress
AND DisplayName0 LIKE ARPName
Little different query, but this allows us to use a wildcard in the mapping table.
Your mapping table can then look this this:
Here you can see a client with Adobe Reader 8.2.0 installed.
You can see the mapping successfully processed in the log.
There you go! Now you can save yourself a number of mappings for products. In my demos for the webcast I had 3 different mappings for versions of Adobe, now all condensed to a single entry.
Thanks to everyone who attended my webcast today. I hope you found the content valuable.
Episode 13: Chris Nackers
ConfigMgr OSD Tips/Tricks – What happens when I do this… uh-oh
Wednesday, May 30th, 2012 ~ 11:00 – 12:30 pm PST
What drivers do you really need in WinPE? Why shouldn’t you just add everything until it works? How does MDT Application Mapping work?
If you want to know these answers then join Chris Nackers, Microsoft MVP as he dives into the world of OSD and answers these questions and more!
I’ve written a few blogs in the past on using a little known feature in MDT where you can deploy applications based on the previous inventory. This a fairly unknown feature that’s been around in BDD/MDT for quite some time.
Brad Tucker over on The Deployment Guys blog has a nice fresh post on the subject using ConfigMgr 2012.
Lets take a look at how we can add some applications the UDI wizard to be presented to the user. This post will cover the basics of adding an application the be presented in the wizard and making it mandatory. There will be later posts on some of the more advanced functions you can do with applications, for example like “mapping.”
First lets configure our package selection screen. We want to configure our server name (1), then refresh the data (2), and then we want to select the application we want to add (3), and finally add it to the select packaged list (4):
Next we want to add the application the list:
Notice that we don’t see Office 2010 listed. This is because in order to show up on the list, the checkbox for allowing this program to be run from a TS needs to be selected.
Now, some interesting behavior with the UDI designer, is that even after checking this box, you still won’t be able to see the program listed. Let me show you below.
Lets refresh our data:
And now try to see the program again:
Still not listed. So what we need to do in order to get the program to show us is actually remove it from the list and re-add it again.
Now it’s listed again:
And now we can actually add it as an application to our wizard:
Now we have it selected and configure other properties if we would like to:
Most commonly, you would pick “Mark as Selected” and/or “Selection Locked”. For this purpose, we are going to leave these cleared and just present it in the wizard. You’ll now have an entry for OSD applications.
If we run the Task Sequence on a machine, we will now see that we have Office 2010 listed as a selectable application:
Now, lets go ahead and add another application, but make it mandatory this time. Here we’ve taken Adobe Reader 9 and marked it as selected and locked the selection.
And when the Task Sequence is ran again, it will show up like this in the wizard and we can see that Adobe Reader 9 is checked and grayed out and we are unable to clear the check box:
Here we can see Adobe Reader installing in the Task Sequence using the options we just showed above:
Now you’ve seen the basics of adding applications to the UDI wizard and presenting them to the user. Along with making a application mandatory to the user, this would be great for items like virus scanning software or other client agents you might want to force to be installed through UDI.
There appears to be an issue in the Install Software step if you are setting your packages dynamically through the database or customsettings.ini. Your case will need to match your program otherwise the application will error out with a “Install Dynamic software action failed to install packageID ‘xxxxxxxx’, programID: "’xxxxxxxxx’. Error Code 0x80004005”. From what I’m told ConfigMgr is case sensative when it processes the package:program relationship.
In my case, “Per-System Unattended” vs “Per-system unattended” meant the failure of about 10 applications that i had set in customsettings.ini. If you are having trouble installing multiple applications, be sure to verify that your case matches what you have for that program exactly.
Deploying Applications Based Upon Add/Remove Programs History – Using Microsoft Deployment Toolkit with SMS/SCCM
The documentation in the MDT toolkit is pretty good, but I did need to change the query to suite my needs. The default query uses ProdID0 in the database, i found that DisplayName0 makes a lot more sense, since that is what you actually “see” when you look at the ARP in Control Panel.
Also to note, that i’ve found it’s a good idea to always make sure you specify your SQLShare property for all your database sections in your customsettings.ini, it’s also a good idea to use a differen share from your logs, i just use a generic SQL$ share that isn’t linked to anything else. Otherwise I’ve seen some errors on the logs because another process owns that share.
So your new stored procedure in the MDT database would be:
CREATE PROCEDURE [dbo].[RetrievePackages]
SET NOCOUNT ON
/* Select and return all the appropriate records based on current inventory */
SELECT * FROM PackageMapping
WHERE ARPName IN
SELECT DisplayName0 FROM DATABASE.dbo.v_GS_ADD_REMOVE_PROGRAMS a, DATABASE.dbo.v_GS_NETWORK_ADAPTER n
WHERE a.ResourceID = n.ResourceID AND
MACAddress0 = @MacAddress
NOTE: Changed ProdID0 to DisplayName0, information returned from ProdID0 was not was I was looking for
Here is the required information needed in your customsettings.ini
Here is an example of the PackageMapping table:
The nice thing about the package mapping is that you can control what is being installed. So if you want to install Adobe Reader 9, you create a mapping for any possible old version and say, Reader 9 is the new version. So you can “map” Reader 7,8 to Reader 9. So if their ARP report shows Reader 8 installed, you can tell it to install Reader 9 instead after the refresh.
The one bad thing about package mapping is that i doesn’t know about licensing. It’s also entirely based upon the DisplayName, so if you have a trial version of something that shows up the same as a licensed version, if you map that in the table, someone who had a trial version will now have a licensed version installed. Just something to keep in mind.
If you have any questions, feel free to contact me… I’ve also attached the documentation taken from the MDT 2008 reference material.
This is a continuation of Part 1 where i discussed a script to configure the network adapters to allow for WOL while in stand-by mode or hibernation mode.
Is this post we’ll address Issue #2
Once you have resolved the issue of being able to bring the devices out of stand-by mode, then you ideally want to keep those machines up indefinitely or at least until the application installs complete. So then you need to either have a group policy or “something” that configures the laptop to stay on after being imaged. I’ll cover this issue in Part 2.
Well here we are in Part 2, so lets address keeping the machines on. It’s great that we have a way to at least wake up the machines from stand-by mode, but it would be even better if we could keep them from going into stand-by to begin with.
I was able to address this issue in our environment by creating a SMS package that configured the laptop power scheme to be “Always On”. Now once a user logs in and changes the power scheme, they could override my setting, but that is fine, my primary concern is dealing with the laptops after they are deployed or refreshed. So once i’m done with what i need to do, the users can adjust the power settings as needed.
I simply created a new package called “Power Config” that has a program called “Always On” that is configured to run unattended. My command line for my program is:
C:\WINDOWS\system32\powercfg.exe /SETACTIVE "Always On"
So, by running it this way, i don’t need to have files on the distribution point for the package to work, right? Well yes and no :) If you are simply deploying this program through the normal software distribution process, then yes, correct you do not need to have files on the distribution point since it’s simply calling a command line that calls a local file.
However, there seems to be a small bug if you are deploying this package through MDT/SMS and are calling the package as part of the OSD process, in my case through customsettings.ini again. So i now have a Packages002=ABC0001:Always On.
However, without any package files actually on the DP, the customsettings.ini process gets a little cranky and you will see the following result in osdswdprogramexec.log
Basically stating that it can’t find the distribution point for the package. Now i’ve seen this before if you don’t have your OSDMP and OSDSiteCode properties configured in customsettings.ini however, i know that i do and that they are correct.
So i simply added a small batch file so the DP has something, and then set the source directory for the package to a folder with that batch file and then updated the DP’s. Once that had been completed, i ran the process again and my install went through just fine. So installing as a package through SMS, worked great without any source files. However, when i tried to call the package through customsettings.ini then i needed to have some files in the DP in order for the package to complete successfully. For whatever reason.
Now that i’ve got this package working through customsettings.ini, it’s again part of the tail end of my imaging process and now not only can i power on my machines if they do go into stand-by mode, but i have been able to configure them to not go into stand-by mode by default after being imaged so hopefully i won’t have to wake them up to begin with.
And that’s it! Hope this helps.
One of the tricks i’ve learned over the years is a way to debug your rules and settings for your ZTI OSD process. If you make a small change, sometimes you just want to see if that change or rule is processed correctly. Which means you don’t want to have actually do a full ZTI every time you want to test a change. If you just want to test a change to your customsettings.ini you can create a quick script and copy a few files to a location and test. The end result will be the logs files you can review to verify the changes.
If you create a folder called “ZTI_Debug”, and then copy your customsettings.ini, ZTIGather.wsf, ZTIGather.xml, and ZTIUtility.vbs into that folder. Then you just need to create a batch file to run the process. The batch file should contain the following lines:
if exist c:\minint\nul rd c:\minint /s /q
cscript.exe ZTIGather.wsf /debug:true
Now, whenever you run that batch file on the target machine or VM, it will process your ZTI rules/queries and output the result to the logs files. On the client under OSDLOGS, you will see the BDD.log, variables.dat, and ZTIGather.log. You can review those logs to verify that your cs.ini is processing successfully, or that your SQL queries are running properly. I often use this process to verify that my packages are being correctly identified, that desktops are getting desktop packages, and laptops are getting the laptop specific packages, etc or test any other changes to my cs.ini that doesn’t require a full refresh to test.
Just a great way to quickly run the rules and process your cs.ini rules without actually doing a refresh.
Hope this helps…
So as i’ve mentioned in previous blogs, i’ve been working with dynamic applications quite a bit lately. The one issue i kept running into lately was 1618 error codes for the execution history. Eventually i was able to resolve everything, but there were a few reasons for those types of errors to show up, so i wanted to create a blog to help others troubleshoot the issue. Obviously the 1618 error messages are related to MSI based installs. So you won’t receive such an error with a setup.exe or another type of install.
I found 2 main causes of the 1618 error codes, and you could have one or both of the issues in your environment depending on configurations.
1) Conflicting installs with SMS 2003
2) SMS Client Health Script
1 – Conflicting install with SMS 2003
I specifically mention SMS 2003 here because from what i understand and have been told, SCCM does not have this issue anymore. Essentially what happens is that when ZTIPackages is installing it’s applications, SMS can also attempt to install it’s applications, so you end up with 2 MSI installs trying to run at the same time and one of them will work, the other(s) will fail with the 1618 error code which is “another installation in progress.” I didn’t run into this problem very often, if at all, on a new computer build, since there wouldn’t be a client history and standing advertisements. However, the problem was very easy to reproduce when doing a ZTI through SMS. Since the advertisements were standing and ready to go, when the machine was doing imaging and back online, there was enough time while ZTIPackages was running for the client to receive it’s policies and attempt to start installing the requested applications.
So, now that we identified the issue, how do we resolve it? Well simply we need to “take care” of the SMS Client, and stop it from doing anything while ZTIPackages is running. The 2 best ways to do this are to either stop the SMS Client Service, or to disable the Software Distribution Component. Disabling the Software Distribution component is a more reliable method, but also has a great risk since you are disabling the component, if your “re-enable” script doesn’t work, you are stuck with a machine or machines that won’t install software until the issue is resolved. Stopping the SMS server (CCMEXEC) works as well, but is less reliable, because if the service starts up again for some reason, you are back to square 1 and installs will start conflicting.
Stopping the CCMEXEC service:
You can use a few methods of stopping the service. You can use simple command lines like “net stop” and “sc stop”, along with “net start” and “sc start”. Or you could use a more advanced method calling a script. Here is a script from the Deployment Guys that allows you to stop and start a service. Here is the usage of the script:
Usage: cscript zCFG-Services.wsf [/service:ServiceName] [/state:Start or Stop] [/debug:true]
NOTE: /service:ServiceName is case sensitive. /state: can be Start or Stop only
Any of the above methods will work, just each have their advantages and disadvantages. Just remember to restart the service back up after the fact. I typically put the stop service command at the beginning of the State Restore phase. I restart the service after User State in the State Restore phase, this makes sure that no program from SMS are running while you are restoring the user state data. The only important thing is that you are stopping and starting the service before/after ZTIpackages, “Install Packages”.
Disabling the Software Distribution agent:
I’ve blogged on this before, so i won’t repost that info again. The information you need is located here: http://myitforum.com/cs2/blogs/cnackers/archive/2009/01/25/pausing-or-stopping-sms-software-distribution.aspx
If you are using this method, I disable the agent before ZTIPackages runs, and i re-enable it after USMT restores user data.
2 – SMS Client Health Script
The client health script is a wonderful script created by some of the guys on MyITForum that work with Dudeworks. This is a great free solution to dealing with common client issues and just keeping a good watch over your clients. Typically you would configure this script to run through Group Policy as a start up script.
I did run into a few issues with the script and conflicting with the Dynamic Applications process. Here are the checks that can be enabled/disabled for the script to verify.
do_CHK_CCMEXEC = true
do_CHK_SYSTEMPATH = true
do_CHK_AUTOUPDATE = true
do_CHK_SMSLOCALADMIN = false
do_CHK_ADMSHARE = true
do_CHK_RemoteReg = true
do_CHK_WMI_SERVICE = true
do_CHK_BITS_SERVICE = true
do_CHK_REGXML = true
do_CHK_AdvClient = true
do_SEND_CCR = true
do_RUN_CCMSETUP = false
do_CHK_CACHESIZE = false
So first off you can see the script is checking for the CCMEXEC service to be started :) Well that’s a problem if we are stopping it for ZTIPackages to run. Depending on the alignment of the planets (or just simple timing), the startup script will see that CCMEXEC is stopped and restart it, which then allows SMS to start running programs again, which will give you the wonderful application conflicts, again.
The next main point of interest is “RUN_CCMSETUP”. If some of the checks fail, the script will automatically initiate a reinstall of the SMS Client. Which is a MSI based install 🙂 So you can also end up with some 1618 failures, because the SMS Client will be reinstalling while ZTIPackages starts running it’s first few applications.
Now if you are using the disable software distribution agent method, software distribution will still be disabled, so the only issue that will likely run into is that the first few applications from ZTIPackages might fail with a 1618 error code because of the SMS Client being reinstalled. In my case, only my first application was failing, everything else would go through successfully after the fact. Quite frustrating. If you are stopping/starting the service, you will most likely have more failures since you will have ZTIPackages and SMS butting heads throughout the ZTIPackages process, it’s first come first serve.
Hope that information helps, let me know if you have any questions.