If WAN Nirvana seems a thousand miles away to you in your deployments, grab a coffee and immerse yourself here for the next half-hour. The tricks I'll be showing today will not only potentially save you many days of work, it just might make your network team fall in love with you[1].
With a few simple steps, I’ll show how you can tweak your infrastructure so that your image and software shares are transparently resolved at deployment time to each client’s local PXE server. The approach I use not only simplifies your software deployments with DS, but it also helps safeguard your WAN links from DS overload from those unintended global software pulls.
Without further adieu, let's get cracking....
[1] Flowers, chocolates, poems and luck may also be required.
Important Note: There is a known issue with DS6.9 SP6 and WinPE4 which means that the PXE environment variables used in this article won't be set. To resolve this please take a look at http://www.symantec.com/docs/TECH213143 and replace your startutl.bat batch file with the revised version in the tech note.
1. Introduction
Computer deployment in a managed environment is rarely a simple case of just deploying an image. It is quite often the case that we are deploying something a bit more complex -an image with software packages and customisations to follow. In well-connected environments such deployments (that we here call builds) present no issue. However, when WAN links come into play, build deployment can wreck havoc if the DS admin hasn't considered where each client will be dragging its image and software sources from.
The good news is that image deployments can be made WAN-aware very simply in DS 6.x (I’ll show how below), but the bad news is that the same cannot be said of software deployment. Altiris assumed that software delivery over WANs would be handled by the Software Delivery plug-in to Notification Server. The result of this thinking was that DS software distribution was never taken to the next level.
Leaving this advanced functionality out of the DS6 product does sadly present problems. DS-only customers obviously miss out, and to a degree Client Management Suite (CMS) customers do too. Everyone is denied access to a fast and efficient build delivery mechanism which reports status back to a single console.
The problem is that textbook deployments by-and-large only consider image distribution. There are good reasons though why you might want to deploy images with software packages to follow as a single build. Here's a couple,
- Compliance
Organisations can require that a computer is built and complies with specific patch policies (both OS and software) before the user logs in. This can be tackled by ensuring images are ALWAYS up-to-date (often impractical) or by following each deployment with software to resolve the compliance issue. Using Notification Server for such compliance is robust but is potentially slow with uncertain timescales. Using DS enables the packages to be delivered immediately in a known timescale providing the desktop team the confidence they are in place before the user logs in.
- Light-Image Deployments
In order to keep the number of managed images to a minimum, many organisations limit the software in their organisational image to include only those packages which are common to the majority of user roles. By providing builds which contain specialist software installs which follow as post-image tasks, Altiris administrators can find they are much more flexible when it comes to provisioning new machines. Yes, software portals are great, but they introduce a delay which in some cases can be unacceptable where the specialist software component is the primary software component for that user.
To resolve the problem of distributing both images and software in WAN connected environments I've seen desktop administrators utilise the following tricks,
- Per-Site Package Clones
This is where you clone a software job and tweak it for use on a specific site. This means for example that your Adobe Reader install job, say "Adobe Reader 9.x", would have the following site clones - "Adobe Reader 9.x -New York Office" and "Adobe Reader 9.x -London Office". The difference between these jobs is that the file copy component would target a suitably provisioned cache at the location specified to respect bandwidth.
This approach works well, but comes at a cost –there is a massive effort involved in duplicating the packages for each site. This can become really cumbersome for the administrator as the system evolves and the number of managed sites increase.
- Microsoft DFS
This great Microsoft technology allows you to create name spaces for your clients which are independent of physical file locations. With its replication component, you have a great solution for enabling clients across multiple sites to download their packages from local sources transparently. Implementing DFS is quite often however not in the remit of the Altiris admin –this requires a higher-level organisational buy-in.
There is another solution which I've used in various forms for many years now which lies between the two offered above in terms of usability. We can modify our software delivery jobs so that their file sources are dynamic and resolve to different locations depending on the PC being targeted. It is certainly a slicker solution than creating per-site package clones, but perhaps not slick as DFS. The great win with this solution is that it entirely within the remit of the Altiris administrator to implement. This can be useful in scenarios where you need to resolve the problem fast.
Here is an overview of what we’ll need to do to achieve our WAN-friendly deployment nirvana
- Package Replication to Site PXE Servers
In order for images and software to be downloaded from your PXE servers, these servers must host suitably provisioned file shares. The details of how you sync your files is up to you, but for the purposes of this article I will assume that you have configured a share called “source” on your PXE servers and within this you have provisioned two subfolders –images and apps.
- Configure Automation to Map Extra Drive to PXE Server
In order for automation to grab images from \\<PXEServer>\source\images we’ll need to tweak automation with an extra drive mapping using Altiris’ Bootdisk Creator.
- Configure Image Deployment for WAN
This is mostly a case of modifying our image distribution jobs so that the images are downloaded from the drive mapping designated for the site PXE Server. In order to record the client’s PXE server permanently as a token, two tiny extra tasks are added in the deployment job set.
- Configure Software Deployment for WAN
Here we amend our file sources to be resolved at execution time using the permanent token we recorded as part of the image deployment above.
- Configure DS Security
In order to upload the token to DS we’ll have to call a stored procedure from a script. The very sensible security model for DS allows us to do this only if we have explicitly permitted the engine access to the stored procedure in question.
Although the Deployment Server side tasks in this article will take less than an hour to setup, be prepared for testing to take perhaps one to two days (environment and WAN bandwidth permitting) to allow software, images and PXE images to replicate.
2. The Classic 'Static' Software Deployment
Before delving into the process which makes our static deployments dynamic, let's take a good look at one of my classic (and static) jobs to deploy Adobe Reader. Once we've reviewed how the job works, we'll then explore the process which makes the job WAN-aware and make this job dynamic.
The bulk of my software deployment jobs can be broken into two tasks -a file copy task and a script execution task. The reason for the initial file copy is that I prefer to execute installs from a local source rather than from a remote share. This is simply for robustness. The initial file copy ensures that the install source is 100% ready and available prior to the install code kicking off. My Adobe Reader deployment job thus looks as follows,
- Copy Task
This task copies our install source across to the target computer. For simplicity let’s assume our source is currently on DS under \eXpress\Apps. The destination is an application cache folder on the target machine’s C:\ drive,
- Run Script Task
This is the task that kicks off the Adobe Reader Installation. My preference with install scripts is to house them as much as possible with the application source rather than embedding the logic within DS. The DS embedded 'Run Script' task then purely act as a bootstrapper to launch the install.bat batch script housed with the package source,
These two tasks look as below when collected into a DS Job, which I’ve called “[I] Adobe Reader 9.3.0 Install”
For completeness, this is what the install source point looks like on my eXpress share,
And here are the contents of my install.bat,
REM Install Adobe Reader
msiexec /i AdbeRdr930_en_US.msi ALLUSERS=1 /norestart /qn
Hopefully, this will pretty much make sense to you. Two tasks –one to copy a remote source to a local location, and a second to execute the install batch file located within it. Note this job has no intelligence -it will always copy the files from the same source.
3. Making Software Deployments Dynamic
At the moment we've got a nice static software deployment job to install Adobe Reader. By static I mean that everything about the job is hardcoded and its execution logic never changes. Of particular interest to us is that the source is always copied to the client directly from the Deployment Server's eXpress share.
In order for us to make this DS job flexible enough for use across a WAN, we need the copy task to be a bit more intelligent. In short, we need such tasks to understand that clients on remote sites require source transfers from the site's local software distribution point (the Altiris PXE Server) -not the deployment server.
To make this happen, we are going to leverage Deployment Server's brilliant token replacement functionality. This is Deployment Server's native mechanism for injecting client specific information into scripts and tasks at runtime. What we are going to do here is to set our COPY task to use a token (if you program, think of this as a variable) for the server name in the UNC path. The Deployment Server engine will then replace this with the client’s local PXE server at execution time using token replacement.
For the token I decided to recycle a native (but generally unused) token from each computer's Location Properties –the %SITE% token. To make our Adobe Reader deployment job dynamic I then simply amend the ‘Copy File’ task as follows,
The DS Engine will resolve the %SITE% token at runtime and use the result as the server hosting the install source. The value for this token is configured in the location properties of each computer. If you select a computer, and navigate to the location data in properties you’ll see something akin to the screen below,
Generally, it is pretty bleak here. At the moment, if we ran the dynamic Adobe Reader install job on this computer the %SITE% token would resolve to an empty string and the software download would fail. We need to populate Site field here with that machines site server for this to work. For example, we could type in a server called AppSourceA here,
This would result in the software download being initiated from \\AppSourceA\apps for just that computer. Editing the location in the console provides us a manual mechanism by which we can configure each machine with its own software source. This is great, but a tad inefficient. The next step is to upgrade this mechanism to include a bit of automation.
4. WAN-Aware Image Deployments and the ALTIRIS_PXE_IP environment variable
Before delving deeper here, let’s take a small step away from software deployment and take a look at imaging. At the start of this article, I talked about the DS admins' requirement to make computer build deployments (image + software) more WAN-aware. The issue being that Deployment Server provides the facility to make image sources dynamic, but not software sources.
The WAN imaging solution that many DS Administrators use is to leverage a site’s PXE server as a local image source. This is made possible by creating a share on the PXE server, setting up a file-sync process, and then adding an automation drive mapping.
For example, we all know that Microsoft automation environments map by default an F:\ drive to the Deployment Server’s express share. Other drive mappings can however be added through Bootdisk Creator to allow images to be deployed from image stores housed separately from your central DS.
I generally configure Bootdisk Creator to map an M:\ drive to the DS eXpress share (I always move the F:\ Drive mapping up to M:\ to make the share mapping more robust on machines where many drives are present), and an N:\ Drive to an image source point on my PXE server. For simplicity, for the PXE server's address I use the ALTIRIS_PXE_IP automation environment variable. This allows a single PXE image (which connects to both the DS and the PXE Server shares) to be used across all the PXE servers in your environment.
So for WinPE we have,
And for Linux heads we have ,
This dynamic drive mapping to the PXE server allows us to configure our image deployment tasks like this for WinPE,
Or like this for LinPE,
This is really neat. The ALTIRIS_PXE_IP environment variable grants us the visibility we need to locate the PXE server in automation so that we can grab our images from it. The problem is however that once we have booted into production the location of the PXE server is lost to the client.
6. Creating a WAN-Aware Build (Image + Software)
It would be great if we could just reference in our software deployments the \\%ALTIRIS_PXE_IP%\source share, but we can't. This variable is natively only configured and set within the Altiris automation environments delivered through PXE.
The trick is then to save this variable in a way which can be used by the engine later. This is where the %SITE% token comes back into play -if we could find a way to save the value of %ALTIRIS_PXE_IP% into the token %SITE% then we'd always have the local PXE server data available to the machine for software source downloads.
This process has gone few incarnations with me over the years and the current one is as follows,
- Boot Into PXE Automation For Imaging
This has to be PXE delivered so we have access to the ALTIRIS_PXE_IP environment variable
- Run automation script to write a token script to the eXpress share
Using the ALTIRIS_PXE_IP environment variable we write a script to the eXpress share which invokes the Altiris SQL stored procedure ins_location. This procedure call is hidden in token replacement syntax and serves to write the Computer's site field in it's Location Properties
- Execute Script Server-Side
This stage executes the script just written to the eXpress share by the Automation task. Although this script looks like a single line comment, it actually hides a SQL procedure which is parsed by the engine prior to execution. It is this parsing which updates the SITE variable for the target computer.
- Deploy Image
Perform the Image deployment as normal
- Deploy Software
Now we can leverage the SITE token to represent the software source.
The key pieces to this process are obviously steps 2 and 3 -creating and executing the token script. The syntax is a tad tricky, so best follow the steps below exactly...
- Create a New Job Called "Best Image Deployment Job Ever"
You don't really need to call it this, but this will be you new template job for your PXE driven image deployments
- Add Automation 'Run Script' Task
If you deploy using WinPE automation, paste the following into your WinPE automation 'run script' window
REM Auto: Write PXE IP to eXpress Share
echo REM ^%%^#*"{call ins_location( %ID%,'%ALTIRIS_PXE_IP%' ) }"^%%>%ALTIRIS_SHARE%\temp\%ID%s.bat
Alternatively, If you deploy using LinPE automation paste this instead
# Auto: Write PXE IP to eXpress Share
echo REM \%\#\*\"\{call ins_location\( %ID%,\'${ALTIRIS_PXE_IP}\' \) \}\"\% >/mnt/ds/temp/%ID%s.bat
The important thing is that this script runs on the client, in the same automation environment that you image in. It's purpose is to create a batch file on your Deployment Server's eXpress share which will look a little like this,
REM %#*"{call ins_location( 5000025,'192.168.157.100' ) }"%
The convoluted syntax with the escape characters in the echo statements is required to ensure the echo is printed correctly. This call syntax in itself is Deployment Server gold dust -executing stored procedures within Altiris' token replacement framework can rid you of all your suboptimal sqlcmd calls to the eXpress database.
- Add Server-side 'Run Script' Task
This job executes the batch file created by the above process. Choose to run the script directly on the deployment server and directly from the file ./Temp/%ID%s.bat. Once this task has executed, your target machines SITE variable will house the IP address of the client machines PXE server
- Add your Imaging Task
Now feel free to add your Image Deployment task, remembering to use your N:\ Drive (or whatever drive letter you've chosen) to connect to the PXE Server's source share
- Add your Software Deployment Task
Now add all you lovely software compliance tasks, using the SITE variable to identify the source server in the 'Copy Tasks'
7. Deployment Server Security
As stored procedures are used to modify and delete data, Deployment Server has a very sensible security bubble it places around code it parses with embedded SQL. This ensures that stored procedure execution from scripts is limited to just those sps you know about and have personally authorised. We now have to authorise the ins_location stored procedure otherwise the engine will block it's execution. This is achieved as follows,
- Open up DS' Program Options from Tools -> Options
- Select the Custom Data Sources tab
- Click the "Allowed Stored Procedures" Button
- Scroll down the lost of SPs and add ins_location to the allows list
Once you clicked the arrow box indicated, it will be added to the "Allowed Stored Procedures" box.
- Click OK
And that's it. You should be good to go!
8. Conclusion
What I've tried to show today is how we can use Deployment Server tokens to allow software deployments to be transparently sourced from your site PXE servers. This provides DS6 customers with a fast and efficient means of deploying image with additional software items across their environment in a WAN-friendly manner.
The method I've shown sets the SITE token in the computer's location properties at build time. This copes with new machines coming into your DS infrastructure. To cope with existing machines, just create a server-side job for each site to update the SITE token as you see fit.
For example, the following comment when executed as a server-side script would update any folder of computers it's dropped onto with the site server 10.0.1.100
REM %#*"{call ins_location( %ID%,'10.0.1.100' ) }"%
The only thing of course that you have to do is to ensure that your PXE servers are provisioned appropriately with both your image and software sources. This can be done free or charge using an bare NS server with no licensing implications by using the Altiris Agent package server functionality. Robocopy also works just as well, or of course any other file-sync technology you already happen to leverage across your Enterprise.
One caveat if you use this is that the ins_location stored procedure will set all other location properties to null. If you don't use the other location fields this obviously there is nothing to worry about. If you in an organisation that does, then you'll need to create you own sp called something like upd_site_location to ensure that only the site token is updated.
Kind Regards,
Ian./