cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Hi all,

I would like to pick your brain.

I need to install a backup utility on Windows 7 (Enterprise) x64 computers.

I need to pass the email address as an attirbute to the installation string so that when it installs, it knows automatically who is the user and creates a backup account for that user in the server and starts backing up immediately.

I thought that I could break the install into 2 parts.

First part, it would run in the user context, get the email address from AD and then store it as a system variable:
Set objADSysInfo = CreateObject("ADSystemInfo")
Set objUser = GetObject("LDAP://" & objADSysInfo.UserName)
Set wshShell = CreateObject( "WScript.Shell" )
Set wshSystemEnv = wshShell.Environment( "SYSTEM" )

wshSystemEnv( "CPUser" ) = objUser.Mail

Set wshSystemEnv = Nothing
Set wshShell = Nothing


The second part would use this system variable and pass it to the installer which is running as the SYSTEM context (we use LANDesk for software deployments):
Set wshShell = CreateObject( "WScript.Shell" )
Set wshSystemEnv = wshShell.Environment( "SYSTEM" )

CurrentDir = wshShell.CurrentDirectory
InstallMSI = "msiexec /i "
InstallPath = CurrentDir & "\install.msi"
InstallOptions = " /qn /l* %temp%\install.log CP_ARGS=CP_USER_NAME=" & wshSystemEnv( "CPUser" ) & " CP_SILENT=true"

'Install Backup Program:
Set objExec = WSHShell.Exec (InstallMSI & Chr(34) & InstallPath & Chr(34) & InstallOptions)
Do While objExec.StdOut.AtEndOfStream
Exit Do
Loop

Set wshShell = Nothing
Set wshSystemEnv = Nothing


However, the first part fails because of Windows 7's UAC, and probably if the end user doesn't have admin rights to write system variables but that's a another issue which I will ignore for now.

I would like for everything to happen completely silently so I'm trying to avoid showing the end user any UACs.

Couple of questions:

1. Is there a way to avoid UACs if I use a digital signature on the installer? How is everyone else managing applications that must run as the user context?

2. Do you have any recommendations on how to do this? Perhaps do everything from the SYSTEM context? If so, do you have any code that I could use to get the logged-on user's email address?

If I run the first part as SYSTEM, it will not return the logged on user's email address as it is looking up the SYSTEMS's account AD attributes which do not exist.

The installer is already an MSI so I'm not sure I should create an MST and a couple of custom actions to get this done.

Any suggestions are appreciated.

Thanks.
(1) Reply
Hi There,

There's two ways that other people are dealing with the UAC issue:

1. Building the install with a setup.exe, and setting the manifest to elevate immediately on clicking setup.exe to start.

2. Indeed as you said, marking the custom action as "Deferred in System Context". This makes it hard to get property values, though.

What you have to do for this approach is use the CustomActionData property, which you set by setting a property equal to the name of the Deferred action containing whatever values you want to get. So if your action is called 'CreateUserAcct' and you need the 'USEREMAIL' property, you'd set up a SetProperty custom action like:

Property Name: CreateUserAcct
Value: [USEREMAIL]

And in your script code, you'd pull the value like:

strUserEmail = Session.Property("CustomActionData")



Also, it's worth mentioning that option #2 is what Microsoft would say you should probably be doing.

Hope this helps!