Chicago Endpoint Management User Group

 View Only

Create DS Jobs That Automatically Pick the Local Package Server for Installation 

Mar 12, 2010 03:28 PM

At the end of this article, you should be able to create a single NT deployment portal or DS6.9 job that will install software for multiple sites and automatically pick the correct installation source. I was holding out for NS7 to see if Altirs would add this functionality but alas, no dice.

At each one of our 30 schools, we have a local server that houses PXE functionality, remote wakeup proxy, and a large D drive which houses an "Express" share where all our software goes. These boxes are HP 5850's running Server 2003 OS because there are times when more than 10 computers need to access its express share at the same time. (30 computer lab install). We refer to them as PXE server even though their primary role is a software installation source.

In the attached zip file, you'll find 3 scripts.

  • IPtopath.cmd should be placed on your master installation source. For us that would be the express share on DS1 (SMDS1). \\smds1\express\scripts\iptopath.cmd
  • SoftwareInstalling.hta is optional and is used to inform your clients that installations are occurring. If you'd like to use it, place it in the same folder as iptopath.cmd
  • Script job template needs to be opened in notepad, all the contents copied, and then placed in a new script job using your DS console or using the NS manage->jobs and tasks Be sure to change the credentials that it runs as so that it has rights to access the package server express shares.
    • script job template msi is the same as the previous but it's for msi installations instead of svs layers.

Walkthrough of the script job template:

Your packagers really only need to edit the first couple lines of code in order to get a new package job working. But you'll need to fix my script with the proper paths for your organization. It's designed to be duplicated into a new job and renamed when you need a new task. This is a template after all.

Rem Install Layer X - this line will show up in DS6.9 as information about what the script is doing. It does not show up anywhere in NS7 deployment portal. It's more of an FYI line.

Layerpath is the first important line. You'll want to specify the path to your vsa file or your .msi file without specifying the name of the server Every one of our PXE servers have an express share and their file structure is identical.

Layer name is the name of the layer that SVS needs to have to activate the job. You can look up this name be loading the vsa file in the svs admin console or using the command "svscmd enum" on the command prompt of a client who has the layer installed.

Set Displaymessage to 1 if you want the user to be notified of the software installation. The name of the software is what you type in the friendly name parameter.

Set IPAddress=%AgentIPAddress" is the cue to altirs to insert the ip address of the client. This ip address is then stored in the IPADDRESS variable.

Next we call the iptopath.cmd file which can natively get the ipaddress we stored in the variable in the previous step.

->Switching to iptopath.cmd

The first line splits the ip address into it's 4 octets and stores them in variables oct1 - oct4

The rest is a bunch of if statements that branch to different package servers in our district and the store the path to the correct server in the variable PXEPATH

DISP is the ip address of the DS I want the DS agent on our image to connect to after sysprep. It requires windows pe scripting code which I won't cover here. You can remove these lines if you like.

I have told this script to exit with an error of 3000 if the client ip address doesn't match a supported range.

->Switching back to the script job template

AFter returning, the job then checks for an error code of 1 or higher. If it gets the mentioned 3000 error code it will exit and return that error to the DS/NS

If not exist %PXEPath%\%LayerPath% This line makes sure the vsa file or msi file exists on the local package server. If not it returns error 3001 so you know you need to fix your installation source or a typo.

if %displaymessage%: This part sees if you want to display the installation message and then does so or skips to placeholder "NOMESSAGE" if you don't want to.

echo ^app^> etc... This line actually builds an xml file called appname.xml which is then read by softwareinstalling.hta. Apparently >< symbols are reserved in the cmd language and so ^ is necessary as an escape character. This makes for a really ugly line of code but it does work. The final > is the redirect command that dumps the echo output to the appname.xml file.

The last few lines are the commands to actually do the installation. The EXITGRACEFUL command was needed because I wanted it to return the real error code and still close the installation message if you are using it. I found that if I tried to use the taskkill command, it would erase the return code of svscmd so I had to preserve it first before using taskkill.

Issues:

On Windows XP SP3 mshta.exe has some issues. Sometimes it only loads up a menu bar with no contents. I have not been able to make this work consistently and so generally we don't use the installation messages. Also, if you run this on a machine where nobody is logged on, it cannot start mshta and therefore cannot taskkill it at the end. The trouble is that it queues up the command and waits for the next person to log on. So on the next logon, someone will get the software installing message but it will never go away since taskkill has already been called.

Development:

Supposedly NS7 has the ability to capture output from a script task to use as a progress update. My scripting tasks don't currently provide any method of status update. It's just done when it's done. Usually you can gauge how long it will take based on prior installations but I'd like to try and implement this feature in the future.

Statistics
0 Favorited
0 Views
1 Files
0 Shares
0 Downloads
Attachment(s)
zip file
DS Scripts.zip   3 KB   1 version
Uploaded - Feb 25, 2020

Tags and Keywords

Comments

Apr 29, 2010 10:14 AM

Hello,

I created another solution that contains only 2 sql stored procedures: 1 on the express (ds) database and 1 on the altiris (ns) database.
The express stored procedure is added to the allowed stored procedure list in de ds console and can be referenced with a token in de software deployment jobs.  For example:

"\\LOCALPACKAGESERVER\software$\...\" will be replaced with "\\%#*"{call site('%ID%')}"%\software$\...\"


What I did was the following:

1. The express stored procedure calculates the subnet of the destination computer based on the %ID% of the computer.
2. The express stored procedure will pass the subnet to the altiris ns stored procedure
3. The altiris ns stored procedure will check if there is a package server assigned for that subnet and will return the ip of the correct package server. the deployment server ip is returned if no server is assigned.


Only NS Site Maintenance should be configured and the same package/folder structure need to be available on all package servers for this to work properly

Greetings :-)

Apr 06, 2010 11:32 PM

Something that could help out anyone with this problem of mutiple sites is using Microsoft DFS/DFSR to manage your software store...

I'm a sysadmin for 10,000 computer company. We have about 70 sites with over 10 computers.
At these sites we have a site server.
Each one of these site servers does a lot of things. DHCP,PXE,Package server, File,Print
We have 4 deployment severs located in our cooperate datacenter.
All of these sites servers have a share that is part of a DFS Name space
that allows me to use the same path on for any site to pull images
the name space is something like
If I map this at any of the 70 site it is always pointed to the local server. The images stored on that server
the local servers have names like svr-sea-inf1, svr-la-inf1
All the data in the tools share is replicated using DFSR
I also have a DFSR folder on my 4 deployment servers to keep anything that I want to access on any of the other boxes. I can make my jobs on the server I use at my site and export then to the DFS folder and import them on my other 3 server without changing anything an I know it will work.
I also in the data folder called Tempdata that is a not replicated folder that I used to temporally store USMT data.
What allows me to do this is a Windows 2003 SP2 domain.

Mar 31, 2010 04:35 PM

We have a script (not sure if I can post it) that makes a call to the NS and requests codebases for the Inventory Agent package (or another DS-specific "fake" package we only assign to certain Package/PXE servers).  The XML returned from the GetPackageInfo call is parsed to grab the package server name, which is then tokenized (we actually create a new row in a custom db table) and reference that for the rest of our installs.  Works out quite well, particularly when you have dozens of remote servers you want to enable this for.  It is dependent on the NS being up, and the Sites & Subnets configuration being correct (so the right PS is returned on the codebases request).

Mar 17, 2010 09:19 AM


Cheers Ian

Will look forward to that, I looked into stored_procedures but alas my SQL are skills are not good enough.

Stewart.

Mar 17, 2010 09:12 AM

Hi Stewo,

I never thought this trick was useful for anyone other than me so I never documented it. I'll write it up as an article so you can see how I implement it. I'm in the middle of an NS one just now, so it will be a couple of weeks....


Mar 16, 2010 04:56 AM

Hi

Thanks folks

Currently have to do all of this manually.

Will look into getting this automated (when i get time)

Cheers


Stewart

Mar 15, 2010 04:31 PM

Hi Stewfo,

What I do is put into cmdlines.txt a line which runs a batch file mycmd.bat. To this batch I have all my cmdlines stuff, and after the PC image is layed down I write an extra line to mycmd.bat which uses the reg command to write a fake add/remove program entry into the registry containing the IP address of the Site Server. When the image is booted into, the agent installs and the registry field added. The next task in the deployment job is to upload an inventory, and then run a SQL script to push the add/remove programs registry field into the clients site server field.

Tricky to setup -took half a day to think of it and get it right. But works a treat.

Mar 15, 2010 03:27 PM

You can do the same thing using tokens for the container that a computer resides in.  You just need to sort your computers into those containers.  
Of course that might only really work well for a smaller solution.

Mar 15, 2010 11:47 AM

Hi Ian

We work along the same lines as yourself to an extent.

Multiple package and PXE servers

Could you expand please

"When you deploy computers, you can also script in the install process the %SITE% field to be configured automatically with the PXE server's IP address. This means that after you've updated your site fields wholesale, the system update automatically with your PC deployments."

on how to automate this.

Cheers

Stewart

Mar 15, 2010 07:27 AM

Given you a thumbs up -good work!

There is alternate approach which i've used which tends to work well for these scenarios where you want to use the NS install sources for both NS and DS in a multi-site arrangement. The steps are,
  1. Decide on a good path naming convention for your jobs
  2. With each NS package you build, force the site server replication to recreate the original folder structure. (This means that on your site server (Package Server + PXE Server) you'll have a nice replicated software install source tree)
  3. Configure each computer on a site to have its "site" field set to the IP address of that site's PXE server
  4. In the DS jobs, reference the job source as being "\\%SITE%\apps\AdobeReader\9.1" etc..
Now when you deploy software from DS, it will always use the source on the local package server. When you deploy computers, you can also script in the install process the %SITE% field to be configured automatically with the PXE server's IP address. This means that after you've updated your site fields wholesale, the system update automatically with your PC deployments.

Kind Regards,
Ian./

Related Entries and Links

No Related Resource entered.