13 Replies Latest reply on Sep 17, 2008 2:30 AM by phoffmann

    Best Practice for Deploying Windows XP SP3?


      Hi all


      We have downloaded XPSP3 (316MB) and are in the process of testing before deploying to 1800+ machines.  We don't use LANDesk Patch Manager and are considering the best way to deploy XPSP3.  Initially, I was thinking we would take the bandwidth friendly advantage of peer download by adding WindowsXP-KB936929-SP3-x86-ENU.exe as an Additional File to an executable distribution package and run with the following switches: "WindowsXP-KB936929-SP3-x86-ENU.exe /passive /forceappsclose /log:c:\XPSP3.log".


      Then, I thought whether it maybe quicker to eliminate the extraction process (5mins+ on some machines) by extracting XPSP3 (400MB) then run \...\i386\update\update.exe with the /passive /forceappsclose /log:c:\XPSP3.log switches.  I am conscious this would put a heavier load on the distribution share.  Also I am pretty certain this method would lose the bandwidth friendly advantage of peer download because there are hundreds of files and folders to add to the Additional Files and wouldn't be practical, but I welcome any suggestions (?).


      Anyone else deployed XPSP3 (without LANDesk Patch Manager) who cares to share how you found it was best done please?







      LDMS 8.5 SP2

        • 1. Re: Best Practice for Deploying Windows XP SP3?
          phoffmann SupportEmployee

          Peer download doesn't particularly care whether you've got a single file or 10,000 files as part of a package - the thing you need to be aware of is that it checks each file individually.


          8.5 SP2 ... hmm - well, it'd be a good thing in general to upgrade, as I don't think that 8.5 has an integrated function to do batch-files (I don't have an 8.5 Core anymore so can't check). But even if it doesn't, you can just work around the problem - by - say - changing it into an Exe for now or so.


          From a "getting files to the clients" point of view, a single file will be easier and faster. It's a single file to copy / cache / and check the hash of, not several 1,000 which I suspect are in the extracted service pack. You could also multi-cast it up-front (multicast -> Cache only) so that you've got a pretty good distribution of it on your network, making peer download more likely to be hitting different hosts, instead of the same one(s) all the time.


          You could then extract the Service Pack on the client machine - assuming you are sure you've got the disk-space - that would eliminate the need to having the SP extracted on a share. (I would suspect you're more likely to loose more time in having the hundreds of files hashes checked than extracting the Service Pack).


          Paul Hoffmann

          LANdesk EMEA Technical Lead.

          1 of 1 people found this helpful
          • 2. Re: Best Practice for Deploying Windows XP SP3?

            Thanks Paul.  I have taken your advice to deploy WindowsXP-KB936929-SP3-x86-ENU.exe as a single file so the package extracts on each client before installing.


            1) I created an Executable package

            2) Added the commands /passive /forceappsclose /log:c:\XPSP3.log to the Install/Uninstall Options tab

            3) Created a Scheduled Task configured as the Policy delivery method (Show Full Interface - No Cancel)

            4) Deployed to a test XP SP2 machine

            5) Once "Active" I ran Policy-Based Delivery on test client, waited for the .EXE (316MB) to copy to SDMCache folder, installed then rebooted. 


            When I logged back on to the test client, I checked SP3 installed ok but the package (sdclient.exe) started to copy/extract/install from scratch.  It had got stuck in a loop. On closer inspection, policy cache reg key on the test client confirmed the package had "failed" and the logfile recorded the 3010 exit code (i.e. reboot required).


            So, it looks like I'll have to apply Jared's advice and use a batch file distribution package instead to deal with the error handling as follows:-




            :: Extract and install Windows XP SP3

            WindowsXP-KB936929-SP3-x86-ENU.exe /passive /forceappsclose /log:c:\XPSP3.log

            IF %ERRORLEVEL%==3010 (

            sdclient.exe /msg="Machine requested reboot"

            EXIT /B 0)



            Will post results.



            • 3. Re: Best Practice for Deploying Windows XP SP3?


              The batch distribution package extracts and installs SP3, the machine reboots, when I login the packages extracts and installs again so it's stuck in another loop (again).  Hmm...


              The logfile (attached) confirms "processing of package is complete, result -1073741502 (0xc0000142 - code 322)".


              One website claims "It's probably better to search for the hexadecimal equivalent, 0xc0000142.




              Initialization of the dynamic link library failed. The process is terminating abnormally."



              The XPSP3 logfie (attached) shows some failures but they could just be red herrings.

              The same happens on 3 machines and the Scheduled Task for each is still "Active" so does not appear to have updated the server (!).


              I was hoping it would be fairly easy to deploy XP SP3, but proving to be troublesome.


              Any ideas please?



              • 4. Re: Best Practice for Deploying Windows XP SP3?


                We abandoned the RunOnce method of installing XP SP3 mainly because  it will not return the final status to the LANDesk server.  So we decided to go for a silent Policy-Supported Push installation using the following code:-



                :: Extract and install Windows XP SP3

                WindowsXP-KB936929-SP3-x86-ENU.exe /quiet /norestart /log:c:\XPSP3.log

                IF %ERRORLEVEL%==3010 (

                sdclient.exe /msg="Machine requested reboot"

                EXIT /B 0)






                Simple but seemingly effective.  It has successfully installed on 6 machines so far without any problems.  I like the fact that SDClient.exe and XP SP3 .EXE use low resources, especially when the the machine is being used.  We prefer it this way, we don't mind if it takes 1-2 hours to copy/extract/install, as long as the user can still use their machine without it grinding to a halt, very neat!    






                How do other peoples' experiences of deploying XP SP3 or any large (300+MB) installations compare?  Do you think we may run into problems with our silent Policy-Supported Push method or have we nailed it this time?






                • 5. Re: Best Practice for Deploying Windows XP SP3?

                  We are still looking to deploy Windows XP SP3 to all machines. We were originally going to deploy using a policy-supported push package but decided against it because we don't want users using their machines during a major change to the operating system in case it causes file-in-use conflicts, etc...

                  We need to find a solution where we can deploy XP SP3 with minimal impact to the users.  Windows Update is not an option because we previously disabled the Windows Update service on all machines to alleviate logon performance issues. 

                  At the moment, our only option is to deploy XP SP3 (i.e. update.msi) via Group Policy Software Installation, but we lose LANDesk's ability to report on those machines that have SP3 installed and those that do not.  We could run a LANDesk Query retrospectively to target the machines without SP3 installed, but it would be much slicker if LANDesk could deploy/report/manage the XP SP3 installation from start to finish.

                  Is it possible to deploy (copy/extract) XP SP3 during the day then install XP SP3 at logoff or shutdown please?  Any other suggestions that fit our requirements are most welcome.


                  • 6. Re: Best Practice for Deploying Windows XP SP3?

                    First, the "install things at Shutdown" trick is not exposed to third party ISVs, so we can't do that. If we trigger off a system shutdown event, then we'll start doing things and get interrupted by the shutdown. So the right time is actually screensaver / idle.


                    Without Security Suite, you need to trick Local Scheduler into picking the right time. Basically, install a Local Scheduler command (see Manage Scripts) set to launch a vbs or batch file or autoit script every few minutes. In the script/vbs/bat, first check to see if the screensaver's on. If it isn't, exit with no change. If it is, install the service pack and delete the local scheduler task.


                    With Security Suite, you'd just use an agent behavior of course.

                    • 7. Re: Best Practice for Deploying Windows XP SP3?

                      Hi Jack.  Thanks for the info RE: shutdown. 


                      I thought there may have been a mechanism whereby the installation starts when the user initiates a shutdown/logoff action, just like WIndows Updates.  But now I know it's not possible (yet) in the LANDesk world. 

                      I like your suggestion (the Local Scheduler in our production Agent is configured to poll every 30 seconds), but have concerns about users returning to their machines and de-activating the screensaver during a 30-60min XP SP3 install, what happens then?  Is it clever enough to 'pause' the installation and continue when the screensaver is re-activated or would it break the installation?  Also, would the final status code for the package be returned to the core server or would we have to run a LANDesk Query retrospectively to see which machines have XP SP3 installed so we can target those that don't?  I am still interested in this approach if our concerns can be satisfied.


                      Ideally, we would prefer to install XP SP3 when the user has no access to their machines but with minimal impact to the user-base, i.e. during logon/startup/logoff/shutdown.  It is a major change to the OS so the intention is to prevent file conflicts, file-in-use issue, etc...

                      If the Local Scheduler method is too risky, do you think the only option for our requirements is to use Group Policy Software Installation (during startup) please?




                      • 8. Re: Best Practice for Deploying Windows XP SP3?
                        phoffmann SupportEmployee

                        What you can do is magic things up a bit creatively.


                        You can use Windows's "auto-logon" feature to help you out. What I'm thinking is essentially a WOL-job over a weekend. The idea is that you'd configure the clients' registry - giving them auto-logon credentials ... but also lock out keyborad + mouse (so no one abuses this), and then run a series of "package A calls Package B, calls Package C" and so on calls, to ensure that everything is going as it should be.


                        We use(d) this trick to upgrade to Internet Explorer 5.5 (in the days of yesteryear) ...


                        ... let me dig up my notes - I don't recommend you use package builder, but it'll give you a good example of what I'm talking about as well as give you a general idea of what I'm talking about. See the attached "IE55_InstallScripts.zip" for the two Package Builder scripts.


                        Now for the explanation / "documentation" as it were...




                        Have an application that not only requires a reboot, but also requires you to actually login to complete the installation? Sounds like a tricky job to script that up, right?


                        There's a good workaround that's worked quite well in the past. This makes use of Windows' own AdminAutoLogon feature (which I assume you're familiar with). If you are NOT familiar with this, please check on Microsoft's TechNet and search for "AdminAutoLogon" - I provide a few links below for conveniance's sake:


                        HOW TO: Enable Automatic Logon in Windows 2000 Professional



                        HOW TO: Enable Automatic Logon in Windows



                        HOW TO DO IT:


                        Firstly, you need to be aware of the following registry keys under "HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\" - I've added comments as to their relevance:



                        • "DefaultDomainName" (should be set to the PC's name - I'll explain why further below).

                        • "DefaultUserName" (Should be set to a local user-account with full admin rights - I'll explain why further below).

                        • "DefaultPassword" (This key needs to be created and is self-explanatory I would think).

                        • "AutoAdminLogon" (This value needs to be set to "1" to enable // "0" to disable)

                        • LegalNoticeCaption (The value for this MUST be empty - I'll explain why further below)

                        • LegalNoticeText (The value for this MUST be empty - I'll explain why further below)



                        One easy way for this is a dual-pronged ESWD package approach. One package to take care of the installation, registry-settings and the first reboot, the second to undo the registry changes and to reboot the server again, so that all is finished. My suggestion would go as follows:




                        Step 1:    Begin by creating an ESWD (Enhanced Package Builder) package which does the following:

                        - Set "AutoAdminLogon" to "0"

                        - Removes the value for "DefaultPassword"

                        - Sets "DefaultDomainName" to whatever your domain is

                        - Sets "DefaultUserName" to whatever your usual domain-admin account is.

                        - If you have chosen to lock out keyboard+mouse in (2), obviously these registry entries also need to be undone.


                        - Includes an command to reboot the server after 'X' seconds (where X needs to be long enough to give the server plenty of time to finish installing the main package post-login. (You can do this by use of the "POWEROFF.EXE" which is in "\Windows\System32" (part of the LDMS client install)). An example command-line for that would be:


                        "C:\Windows\System32\Poweroff.exe 600 /REBOOT" - this will reboot the system after 600 seconds (10 minutes).


                        NOTE:    Poweroff is CASE SENSITIVE - so "/REBOOT" must be in captials!




                        Step 2:    Create a second ESWD package, which does the following:

                        - Set "AutoAdminLogon" to "1"

                        - Set "DefaultDomainName" to the PC-name (use the $MACHINENAME$ to help you here) so that it performs a local log-on. I'll explain this in a moment.

                        - Set "DefaultUserName" to a local-administrator (which I assume you've created).

                        - Create/Set "DefaultPassword" to whatever password the local administrator has.


                        - Start the install of the main package (Norton AntiVirus).

                        - Add an entry to the "RunOnce" key to call the (small) ESWD-package created in (1).

                        - If you should chose to do so, you can lock out mouse + keyboard via registry as well (for security). If you do so, make sure you re-enable this in the registry in the package created in (1).

                        - Reboots the PC (as per usual) once Norton AntiVirus has done it's side of the installation.


                        Step 3:     You're done :).




                        WHAT'S HAPPENING AND WHY:


                        The above may seem a little confusing, so I'm going to explain things a little.


                        A: You add registry-entries to allow you to do the auto-logon (2) according to your desires.


                        B: I suggest that you use a LOCAL admin-account as opposed to a domain-account, as this makes you more resilient towards dodgy domain-trust relation ships. This way, you've not got to worry at all about domain-trusts that aren't working 100% and might be causing problems - because you log on locally.


                        C: You create a registry entry in RunOnce (2) that calls the package created in (1). The package created in (2) starts everything (including the Norton AntiVirus install), and the package in (1) undoes the changes so that everything is put back to normal again, as well as rebooting the PC a second time.


                        D: You require 2 reboots. The first to complete your application install (with the auto-logon). The second, to apply the Registry changes which the small package (1) did, to reset your server to normal.


                        E: The "LegalNoticeCaption" and "LegalNoticeText" registry keys MUST be empty, because they will prompt for a click-able "OK" box, which will break the auto-logon process.


                        This should help.


                        IE5.5 install - a practical example:


                        Olivier Herve kindly provided some example scripts which were used for an IE5.5 install and had to go through just what was described above. There is also an addition here for security - keyboard + mouse lockout. That's THIS section in IE55SP1.CFG:


                        KEY: new, "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mouclass"
                        VALUE: reg_dword, replace, "start", "4"
                        KEY: new, "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kbdclass"
                        VALUE: reg_dword, replace, "start", "4"


                        If you're doing a login-requiring install on a server (especially remotely), you might want to lock out mouse + keyboard for any potential interference. The reasoning here would be for instance that - during those "completing install minutes" anyone could just use the PC and create themselves a local admin-account.


                        With a locked-out keyboard + mouse this is no longer an issue. Just remember to include the reset to this in your restarting-script. The following is from RESTART.CFG to enable keyboard + mouse again:


                        KEY: new, "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mouclass"
                        VALUE: reg_dword, replace, "start", "1"
                        KEY: new, "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kbdclass"
                        VALUE: reg_dword, replace, "start", "1"


                        The scripts included are meant as a good starting point, should you need it.


                        I've uploaded these scripts to this comment




                        Credit goes to Jon Giffard who provided the information for this Tech Hint.

                        Credit for the ESWD-script files goes to Olivier Herve.




                        Paul Hoffmann

                        LANDesk EMEA Technical Lead

                        • 9. Re: Best Practice for Deploying Windows XP SP3?

                          Paul's method is the right way to do it. My method is better for shorter running tasks.

                          • 10. Re: Best Practice for Deploying Windows XP SP3?
                            ahe Expert



                            last week I got a hint from Microsoft, what to do and check to deploy SP3. We've the same problem to actualize our clients ...



                            • 11. Re: Best Practice for Deploying Windows XP SP3?

                              Thanks Paul/Jack/Axel for your suggestions/advice.


                              Paul, 1) using the local admin account may pose a problem in that the password is different on each machine based on the following format <machineID><additional word> (this is set by a VBScript during the build process). 

                              2) WOL may not be an option because I believe it is BIOS-disable on most, if not, all Dell/Toshiba laptops (1000 ish in total), so we may have to rely on communication with the business as to when we will deploy XP SP3.

                              3) Also, even though I have used Package Builder in the past, I am more comfortable using batch files instead so I assume I could get the same results with batch files instead?




                              • 12. Re: Best Practice for Deploying Windows XP SP3?
                                MarXtar ITSMMVPGroup

                                If you have some good vbscripting in the organisation could you assign a vbscript as a machine level gpo instead?  Use LANDesk to distribute out the installation files so you get the distribution benefits but use the vbscript to detect if the machine needs updating and launch the service pack?


                                Wouldn't normally suggest this but since you have a particular preference to launch before people log in, why not see if you can do this?


                                Mark Star - MarXtar LANDesk Enhancements

                                Home of Power State Notifier & Wake-On-WAN for LANDesk

                                • 13. Re: Best Practice for Deploying Windows XP SP3?
                                  phoffmann SupportEmployee

                                  Aye - what Mark said is certainly valid.


                                  As for the other things.


                                  Axel - thanks for sharing your doc - I'll have a read through it to see what's in it. Now on to Scott.


                                  Re #1 -- well - you could work around this by either creating a new local user, or you could have your "local logon script" have a data-file along with it, and have a - say - VB script get the machine name, and then cross-check the CSV-file for the machine name and put in the right password.


                                  Not "great", but that's what happens for non-uniform passwords. Of course, while uniform passwords are convenient, they can be a security risk, so ... :).


                                  Re #2 - ah - that's unfortunate. My advice would be to teach your rollout department to make sure that WOL is enabled. That won't help you "right now" but it will help you in the future at least. Equally, you can try contacting your OEM's (Dell + Toshiba in this case) to find out if the laptops you use have got a BIOS-scripting tool (some do) -- this way you could enable WOL essentially via remote script. Assuming that those laptops do have such a tool ... not all do.


                                  Re #3 - The package builder script was given as an EXAMPLE. It's about "WHAT to do" - not "thou must do it in this way". You can use VBScript, Batch, AutoIT - anything you care for - choose your own poison :). I just wanted to give you an example of how it could be done, so that you have a starting point :).


                                  Paul Hoffmann

                                  LANDesk EMEA Technical Lead