#201279 - 2010-12-23 06:18 PM
@PRODUCTYPE fails due to User Profile lock
|
Sergey_G
Just in Town
Registered: 2010-12-18
Posts: 3
Loc: Canada
|
Hello All,
I have written a logon script that includes the following statement to log users out of Windows 2000 systems and to log the event to the share:
IF @PRODUCTTYPE = "Windows 2000 Professional" OR @PRODUCTTYPE = "Windows 2000 Workstation"
Open (1, "\\##########################", 4)
Writeline (1, @CRLF + @USERID + " " + @WKSTA + " " + @LDOMAIN + " " + @DATE + " " + @TIME + " " + @PRODUCTTYPE + @CRLF)
Close (1)
MessageBox("Windows 2000 workstation use is no longer supported on GE
Water domains. You will be logged off after a 20 second wait, or upon
pressing OK. If you require an exception, please obtain manager approval
and contact Helpdesk.", "LOGOFF WARNING", 0, 20)
$RC = LOGOFF( 1 )
Endif
It looks like on workstations with particularly heavy User Profile lock issues (Userenv 1517 and 1524), the script may fail to detect the productype, returning <unknown:PRODUCTTYPE<unknown:. This is an intermittent event, usually cleared by reboot. When it happens, the above If statement executes for any operating system.
I have a workaround in mind, that places an exit statement prior to the logoff statement, targeting systems other than Windows 2000, for which the script should not be executing:
If @PRODUCTTYPE = "Windows Server 2003 Domain Controller" OR @PRODUCTTYPE = "Windows 7 Professional Edition" OR @PRODUCTTYPE = "Windows 7 Ultimate Edition"
Exit
EndIf
My thinking is that on a sysytem with the @PRODUCTYPE error condition, the If statement should exit the script prior to the logoff action. Could you please tell me if this is an accurate assumption? Also, is it possible to predicate an If statement on an Unknown producttype?
I have been trying to simulate the issue in lab. But when I deny access to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion for the logon account, the script does not execute. When I remove the ProductName value, the change does not take hold until relog, and the relog fails with an LSASS error. When I deny access to the HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions Registry key, @PRODUCTTYPE still returns the correct value. If you could inform me of a way to simulate the issue, it would also help greatly.
Thank you,
Sergey
Edited by Sergey_G (2011-04-14 10:25 PM)
|
|
Top
|
|
|
|
|
#201292 - 2010-12-24 06:28 PM
Re: @PRODUCTYPE fails due to User Profile lock
[Re: Glenn Barnas]
|
Sergey_G
Just in Town
Registered: 2010-12-18
Posts: 3
Loc: Canada
|
Much appreciated, Gentlemen!
Yeah, the User Profile lock can be caused by AV, but in our environment, it can usually be traced back to sessions being open too long with too many applications running on an older image. Installing UPHClean everywhere could help, but I cringe at the thought of proposing the intiative to be implemented on the global enterprise network. Not so much because it's a bad idea, but because the corporate philosophy of "the less change the better" is so deeply entrenched.
True, it would be too optimistic to hope to catch every error. Right now I have this bit of script to try to catch any instance of the error where the script exits, instead of logging out the user:
If @PRODUCTTYPE = "Windows Server 2003 Domain Controller" OR @PRODUCTTYPE = "Windows 7 Professional Edition" OR @PRODUCTTYPE = "Windows 7 Ultimate Edition"
Open (1, "\\##########################", 4)
Writeline (1, @CRLF + @USERID + " " + @WKSTA + " " + @LDOMAIN + " " + @DATE + " " + @TIME + " " + @PRODUCTTYPE + @CRLF)
Close (1)
Exit
EndIf
Then the logout statement follows.
I got the known offenders in the test OU, where this test exit statement runs, so I figure if I can catch even a few instances of this working, and no instances of it failing, I'll have sufficient proof of concept.
I doubt the missing quote is the cause, because the failure is only on a few machines, on which the Userenv 1517 and 1524 are particularly bad, and following reboot, the script runs fine, as it does from the start on most machines. This is why I lean towards profile lock blocking @PRODUCTTYPE from reading the relevant Registry. If I get the chance, I'll definitely try out the if instr(@producttype,"unknown") - it should shed considerable light on exactly how the "unknown" value gets treated. There certainly seems to be something different about it, as an If statement that is predicated not on "unknown", but on other explicit values, nevertheless executes when it is handed the "unknown" value. Really threw me for a loop, that did. This Sanity UDF sounds great, I will definitely check it out, and the input accept script will be very handy for when more exact data gathering is required.
Thank you both,
Sergey
|
|
Top
|
|
|
|
|
#201401 - 2011-01-17 02:32 AM
Re: @PRODUCTYPE fails due to User Profile lock
[Re: Les]
|
Sergey_G
Just in Town
Registered: 2010-12-18
Posts: 3
Loc: Canada
|
heyy, Les! that mismanaged environment would be General Electric. perhaps you could do a better job with hundreds of thousands of users working in hundreds of semi-autonomous environments. anyway, it's getting managed now. true, there are other ways to handle this sort of issue in Group Policy, but i was told to do it this way. if it doesn't work, we'll try something different. people are always more willing to argue with somone else's boss, or, for that matter, with someone else's technology.
thank you for all your help, gentlemen. i have a test solution ready that will log errors - i don't think, given the realatively low incidence of the issue, concurrent writes to error log will prove to be a problem, but i do appreciate the heads up, Allen. just waiting for approval to run it. if i should find anything of possible interest to you, i'll be sure to post it. please consider this question answered.
|
|
Top
|
|
|
|
Moderator: Glenn Barnas, NTDOC, Arend_, Jochen, Radimus, Allen, ShaneEP, Ruud van Velsen, Mart
|
0 registered
and 2220 anonymous users online.
|
|
|
