Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

My Altiris 7.0 to 7.1 GPO upgrade script

Created: 06 Oct 2011 • Updated: 04 Jun 2012 | 6 comments

I thought that I would share the script I'm currently using to upgrade (almost) everything in our environment from Altiris 7.0 to 7.1.  We're doing a live/live migration, so in my case both environments are still available.  Initially, I tried just tried a simple redirection of the agent to the new NS.  This failed miserably as it broke my x64 clients.  I'm not sure *exactly* what broke, but the end result was that the agent service wouldn't start on any x64 OS.  Maybe someone here knows why.  In the end, I don't really care because it seems that a clean and install process is a much better way to handle the migration.

Anyway, there are just some simple requirements.  

- I found that scripts didn't run properly from a GPO if it wasn't in the Netlogon folder, so start by creating a new folder called AltirisAgent in your \DOMAIN\NETLOGON folder.

- You'll need PSEXEC which is available for download from MS here: http://technet.microsoft.com/en-us/sysinternals/bb897553.

- You'll need AeXNSCInstSvc.msi from \\YOUR*NS\nscap\bin\Win32\X86\NS Client Installation\

I've attached the script I used. You'll obviously need to edit everything in the Configurables section.  The script idea came from the website listed below, but I added some logging, removed stuff I didn't care about, and cleaned it up a bit.

I set this as a startup script, which means it will only install as things reboot.  Seemed like a relatively good way to slowly move things over.  Eventually I'll push out a job in our 7.0 environment that will migrate things that haven't rebooted...

Original inspiration:

http://www.xcendgroup.com/2010/09/xcend-tech-tips-installingupgrading-the-altiris-agent-via-active-directory-group-policy-startup-scripts-including-windows-vista-and-above-clients-%E2%80%93-notification-server-7/

Comments 6 CommentsJump to latest comment

KSchroeder's picture

Hi Zac,

Thanks for sharing this; I'm using it as a baseline for my migration as well (though I'm going from 6.0 to 7.1, and will use the 6.x Agent to push this script instead of a GPO, but I do have a GPO for 6.x as well). Any reason why, since your script is running as a machine startup script, that you can't just execute the AltirisAgentInstSvc.exe directly, instead of running it through PSEXEC first?  I definitely see the benefit of running the installer service (after pre-caching the AeXNSC.exe,so you can pass the -notrayicon which AFAIK you can't pass to AeXNSC.exe directly).

Thanks,
Kyle
Symantec Trusted Advisor

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.

Zac H's picture

I have no idea how this just got posted, as I made this post probably six months ago.  Anyway...

The reason for psexec is to overcome any possible UAC issues with Vista/Win7.  It's likely not needed for the startup script, but sometimes our techs need to run it manually as well and I didn't want to have to maintain a seperate script for that.

K. Kennedy's picture

That's correct.  If you run the script from a network share, then the Program Compatibility Assistant (PCA) in Windows 7 that checks for UAC compliance will not complain with a pop-up (program may not have installed correctly...).  Programs run from a share are automatically excluded.  So psexec is not needed in that case.

KSchroeder's picture

Ahh OK that makes sense.  Also it had been here, but either when you posted it, or after some period of inactivity, the comments were disabled.  I re-enabled them so I could ask my questions smiley.

I'm going to set my version to not only install the core agent, but also all of the plug-in/sub-agents as well, just so we can have a fully-functional client ASAP (and not have more load on the NS and PS/SS while initially migrating).

Thanks again for sharing this.

Thanks,
Kyle
Symantec Trusted Advisor

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.

K. Kennedy's picture

This script is excellent, but if you had previously deployed 7.0 agents on a 64-bit O/S, it will leave the old  AeXAgentUtil.exe in the .\Program Files (x86)\... directory structure, and this might cause some confusion for support people later on.  The reason it is left orphaned is that most of the files in 7.1 are now 64-bit compatible, so they will be relocated to the regular .\Program Files\.. directory structure, so this file is not overwrtitten/upgraded.

So in the CleanAgent() subroutine, you might want to put:

oFSO.DeleteFile sUtilPath & "\AeXAgentUtil.exe"

after the statement:

Log("AexAgentUtil gave return code " & iRC & ".  Clean successful.")

--------------------------

Update: There is a possibility the above delete statement could fail/throw an error if the AeXAgentUtil.exe process did not close right away.  Also, if you ever wanted to use a modified version of this script to do a reinstall of 7.1 agents, I don't think the script is good enough because I've noticed multiple AeXAgentUtil.exe processes can start up if running the 7.1 version of AexAgentUtil /cleanup. 

Attached is a version I'm using that checks that the process no longer exists before continuing with the cleanup/install.  It also has a little better code to prevent it from running on the SMP server or any site server as an extra layer of protection.  Use at your own risk/test for your environment.  I commented out the psexec statements because I will be running from a network share...

AttachmentSize
Altiris71Upgrade.vbs_.txt 6.93 KB
Zac H's picture

Excellent idea. I didn't really worry about it initially since not everything is x64 yet, so you'll still end up with an Altiris folder and files under Program Files (x86).  Or last I checked you will anyway...