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

Deploying Sametime 8.5.2 Via DS 6.9 SP5

Created: 31 Oct 2012 | 5 comments
ljc's picture

Hi All,

 

We have a company requirement to upgrade to Sametime 8.5.2 embedded client for Lotus Notes 8.5.2 (I know, dark ages and all that). I've had problems with this deployment since the start and I've finally run into one that I simply cannot figure out.

 

Environment:

Deployment via DS 6.9 SP5

Clients are run a Windows 7 x64 based MOE 

The issue:

The deployment itself is quite messy with VBS dialogs asking whether the user wants to continue ect, all of that works and isn’t relevant as far as I can tell to the issues we’re having. The install portion of the deployment is just a run script containing this

 

cd "C:\basebuild\asa\sametime\sametime connect"

c:

mkdir C:\BaseBuild\Logs

msiexec /I SametimeEmbedded.msi /passive /l*v C:\BaseBuild\Logs\sametimeconnect.log

 

When the install is run on the local system account, the install gets to a point and then just halts, the last few lines of the msiexec log are the following

XPD: 31/10/2012 15:53:53 Provisioning/getLogStatusUpdates: DEBUG - Looking for C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\.prov2install or C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\provisioning.log

XPD: 31/10/2012 15:53:54 Provisioning/getLogStatusUpdates: DEBUG - Looking for C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\.prov2install or C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\provisioning.log

XPD: 31/10/2012 15:53:55 Provisioning/getLogStatusUpdates: DEBUG - Looking for C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\.prov2install or C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\provisioning.log

XPD: 31/10/2012 15:53:56 Provisioning/getLogStatusUpdates: DEBUG - Looking for C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\.prov2install or C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\provisioning.log

XPD: 31/10/2012 15:53:57 Provisioning/getLogStatusUpdates: DEBUG - Looking for C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\.prov2install or C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\provisioning.log

XPD: 31/10/2012 15:53:58 Provisioning/getLogStatusUpdates: DEBUG - Looking for C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\.prov2install or C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\provisioning.log

XPD: 31/10/2012 15:53:59 Provisioning/getLogStatusUpdates: DEBUG - Looking for C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\.prov2install or C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\provisioning.log

XPD: 31/10/2012 15:53:59 Provisioning/getLogStatusUpdates: DEBUG - Found C:\Users\altiris\AppData\Local\Lotus\Notes\Data\workspace\logs\.prov2install

 

Once the install gets to this point, it will just sit, forever, with msiexec still running as a process until it is manually ended.

 

The part that has me stumped in all this, is that if you run the install script from above manually on the machine, it will install fine, if you run the deployment as a specific user with admin rights and then login as that user, it will also work correctly. It’s almost as if the installation has to be run in the console session. However this doesn’t work for me deploying to 2220 users the majority of whom don’t have administrative rights on their local machines.

 

Does anyone have any thoughts?

Thanks,

Liam.

 

Comments 5 CommentsJump to latest comment

andykn101's picture

Try with the /quiet option instead of /passive. There may be a message displayed even with /passive that you're not seeing because it's a hidden session that will be logged properly with /quiet.

if you are running this as the Local System account why is the installer looking in the "Altiris" user's profile?

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

bhawver's picture

Expanding on Andy's response above, I've found that some programs don't like being installed in Windows 7 as a system account as they depend on a legitimate profile.  I would suggest the install be run as a legitimate user that as admin rights on the machine (i.e. a local administrator account or domain account that has admin rights on all of the machines).  You might find this will work for you.

Brian Hawver
Systems Engineer
Yaskawa America, Inc.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

ljc's picture

Thanks for both of your replies, I've tried the quiet switch and still had no luck. The logs have the user "altiris" in them because I did try bhawver's advice and tried running under a domain admin level account instead of the system account. Still with no joy.

andykn101's picture

The next thing I'd look at is to not create directories in the root of C: but in a location like %temp% or %localappdata%\appname

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.