Search results matching tags 'Operating System Deployment', 'MDT 2008', and 'Dynamic Applications'

Deploying Applications Based Upon Add/Remove Programs History – Using Microsoft Deployment Toolkit with SMS/SCCM

cnackers — Tue, 03 Nov 2009 05:00:00 GMT

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]

@MacAddress CHAR(17)

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

Priority=DynamicPackages

[SMS]

SQLServer=SERVER

Database=SMS DATABASE

Table=v_Program

Parameters=PackageID,ProgramName

SQLShare=SQL$

NetLib=DBNMPNTW

[DynamicPackages]

SQLDefault=DB_DynamicPackages

[DB_DynamicPackages]

SQLServer=SERVER

Database=MDT DATABASE

StoredProcedure=RetrievePackages

Parameters=MacAddress

SQLShare=SQL$

NetLib=DBNMPNTW

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.

Deploying Applications Based Upon Add/Remove Programs History – Using Microsoft Deployment Toolkit with SMS/SCCM

cnackers — Tue, 03 Nov 2009 05:00:00 GMT

So your new stored procedure in the MDT database would be:

CREATE PROCEDURE [dbo].[RetrievePackages]

@MacAddress CHAR(17)

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

Priority=DynamicPackages

[SMS]

SQLServer=SERVER

Database=SMS DATABASE

Table=v_Program

Parameters=PackageID,ProgramName

SQLShare=SQL$

NetLib=DBNMPNTW

[DynamicPackages]

SQLDefault=DB_DynamicPackages

[DB_DynamicPackages]

SQLServer=SERVER

Database=MDT DATABASE

StoredProcedure=RetrievePackages

Parameters=MacAddress

SQLShare=SQL$

NetLib=DBNMPNTW

Here is an example of the PackageMapping table:

If you have any questions, feel free to contact me... I’ve also attached the documentation taken from the MDT 2008 reference material.

Dealing with Laptop Standby Power Mode – Part 2

cnackers — Wed, 22 Apr 2009 04:00:00 GMT

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

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.

Dealing with Laptop Standby Power Mode – Part 2

cnackers — Wed, 22 Apr 2009 04:00:00 GMT

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

Issue #2

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"

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

And that’s it! Hope this helps.

Dealing with Laptop Standby Power Mode – Part 2

cnackers — Wed, 22 Apr 2009 04:00:00 GMT

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

Issue #2

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"

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

And that’s it! Hope this helps.

Debugging SMS 2003 OSD Processes

cnackers — Tue, 21 Apr 2009 04:00:00 GMT

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:

:Start:

if exist c:\minint\nul rd c:\minint /s /q
cscript.exe ZTIGather.wsf /debug:true

:End:

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…

Debugging SMS 2003 OSD Processes

cnackers — Tue, 21 Apr 2009 04:00:00 GMT

:Start:

if exist c:\minint\nul rd c:\minint /s /q
cscript.exe ZTIGather.wsf /debug:true

:End:

Just a great way to quickly run the rules and process your cs.ini rules without actually doing a refresh.

Hope this helps…

Debugging SMS 2003 OSD Processes

cnackers — Tue, 21 Apr 2009 04:00:00 GMT

:Start:

if exist c:\minint\nul rd c:\minint /s /q
cscript.exe ZTIGather.wsf /debug:true

:End:

Just a great way to quickly run the rules and process your cs.ini rules without actually doing a refresh.

Hope this helps…

Dynamic Applications – 1618 error codes

cnackers — Fri, 30 Jan 2009 05:00:00 GMT

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

zCFG-services.zip zCFG-services.zip

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.

ZTI-SMSSD-Scripts.zip ZTI-SMSSD-Scripts.zip

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.

-Chris

Dynamic Applications – 1618 error codes

cnackers — Fri, 30 Jan 2009 05:00:00 GMT

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

Stopping the CCMEXEC service:

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

zCFG-services.zip zCFG-services.zip

Disabling the Software Distribution agent:

If you are using this method, I disable the agent before ZTIPackages runs, and i re-enable it after USMT restores user data.

ZTI-SMSSD-Scripts.zip ZTI-SMSSD-Scripts.zip

2 - SMS Client Health 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

Hope that information helps, let me know if you have any questions.

-Chris