Forgive me if this is a dumb question but…

We deploy stuff via Altiris Notification Server to machines whether of not they are logged in. So if they are logged out at the time of deployment NT AUTHORITY\SYSTEM installs the package, the user logs in, clicks the shortcut and the package repairs (if its not advertised active setup runs on login). No problems there.

However if the machine is logging in at the time of deployment NT AUTHORITY\SYSTEM still installs the package but it doesn’t write current user data. I assume this normal behaviour? So if I don’t have any entry points, and I don’t want to have logout and in to run an active setup, what’s the deal with writing CU stuff?
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


You could run a custom action - check if anyone is logged on, if they are run regedit -s to add a CU reg frag...

Wise script example:
Get Registry Key SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon place in Variable LOCALUSER
Check In-use File C:\Documents and Settings\%LOCALUSER%\ntuser.dat
If FILEUSE Not Equal "In-Use" then
Execute C:\Program Files\marimba\Delivery\CL00328\psshutdown.exe -r (Wait)

Hopefully you wouldn't need to employ this too often as mostly you'd hope to have entry points, mostly


I refer to this scenario as a window of disopportunity and would generally rely on Active Setup and the old support adage when something doesn't work after deployment "... have you tried rebooting and ring back in ten minutes (as I'm about to go to lunch)?"
Answered 04/04/2007 by: AB
Purple Belt

Please log in to comment
Cheers dude – I’m going to go with the ‘let the helpdesk sort it out’ approach [:)]

Answered 04/04/2007 by: fuz_kitten
Second Degree Blue Belt

Please log in to comment
Check In-use File C:\Documents and Settings\%LOCALUSER%\ntuser.dat
This is not the best way to identify a user's profile.
1) C:\Documents and Settings\ is not a certainty. It has been replaced with something like C:\Users\ in Windows Vista, and admins can choose to point profiles somewhere else.
2) The user's profile is not guaranteed to be equal to his/her username. It could be Username.001 or Username.Domain. Or worse, the user's username could have been changed from, say, Johnson to Smith (maybe the user got married), so now you have a user named Smith using a profile named Johnson.
To make this work, I think you'd have to find out the user's SID, then look up the value of the expandable string "ProfileImagePath" under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>.

I'd imagine that there's a better way to determine whether or not somebody is logged on, but I don't know how to do it. Anybody else have any slick ideas?

Maybe you could create a complementary job in NS* to run in the user's context (set to run only when a user is logged on) to push down the desired CurrentUser stuff. Maybe in the job itself, you can program it to only install if the Active Setup task hasn't already done its job (if you want to avoid installing twice) or maybe you could use Altiris instead of Active Setup.

* Please bear with me as my knowledge of Altiris is somewhat limited. I'm basing this on past experience and I'm not sure if you can do exactly what I've described.

Answered 04/04/2007 by: mazessj
Blue Belt

Please log in to comment
Thanks for you brain power guys. That’s a very good point about the profile name not necessary being the same Josh.

Maybe LogonUser could be used some how, I don’t know, seems lots of work for little reward. I’m just going to get NS to only deploy to machines that are not logged on. Lazy, but hey…

Answered 04/05/2007 by: fuz_kitten
Second Degree Blue Belt

Please log in to comment
Hi Josh,
your right with this hard coded path.
But there is an elegant way around this, IMHO: Just use the %USERPROFILE% environment variable.
Regards, Nick
Answered 04/05/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
just a small item about how it doesnt write the CU data but it doesn’t write current user data.

actually you will find it does write the HKCU for the user whom is logged in at the time.

so it will be writing the HKCU to the NTAuth account. Which has no profile so before you know it, it will be gone.

im guessing this will be a very small amount of apps that have no entry points and are exposed to this issue.
Answered 04/18/2007 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment