As everybody is probably already aware, we use Novell ConsoleOne and Zenworks where I work. ConsoleOne has some interesting features that require that whenever a Group Policy is being edited it takes over as the policy on the machine that is editing it. Rather than have a useful tool like Microsofts Group Policy Management Console, Novell likes to replace the local Group Policy and then just run gpedit.msc. Which is where my first gripe about gpedit.msc comes in:

GPEdit.msc requires line by line entry of things like, for example, port exceptions and program exceptions for the Windows Firewall. This is usually not an issue except that, as I have discussed in previous posts, we have been moving towards a Windows Domain environment. Firewall Exception rules are configured within two places in Group Policy: Domain Profile and Standard Profile. I have found that there is a need to move our current Standard Profile settings across to the Domain Profile settings. After a bit of registry searching I found a neat trick for doing exactly that.

In Novell, when a GPO is opened in gpedit.msc the Group Policy Contents are loaded into the normal registry locations (as per a normal GPO being applied to user and machine) and the contents are also loaded under a specific pair of registry keys. The HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects Key is created on loading gpedit.msc, and underneath a pair of Keys are created like {449E44B0-A4DC-4665-AE8F-68710E1BC1EC}Machine and {449E44B0-A4DC-4665-AE8F-68710E1BC1EC}User, where the GUID is randomly generated (or at least seems to be random) each time gpedit.msc is run. Under these keys are the branch on which the Group Policy Settings are configured.

So therefore in order to duplicate StandardProfile Settings I need to duplicate all keys and values underneath HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{GUID}Machine\Software\Policies\Microsoft\WindowsFirewall\StandardProfile\, where {GUID} is the randomly generated GUID for editing a Group Policy Object. So far from my research I have never seen more than one GUID appear underneath the Group Policy Objects key, though your mileage may vary. So the first step is to get the User and Machine keys from under the Group Policy Objects key.

Const HKEY_CURRENT_USER = &H80000001
Const HKEY_LOCAL_MACHINE = &H80000002
 
Const REG_SZ = 1
Const REG_EXPAND_SZ = 2
Const REG_BINARY = 3
Const REG_DWORD = 4
Const REG_MULTI_SZ = 7
 
strComputer = "."
 
Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
 strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\"
strStandardPath = "\Software\Policies\Microsoft\WindowsFirewall\StandardProfile\"
strDomainPath = "\Software\Policies\Microsoft\WindowsFirewall\DomainProfile\"
 
If keyExists(HKEY_CURRENT_USER,strKeyPath) Then
  subkeys = GetSubkeys(HKEY_CURRENT_USER,strKeyPath)
  If Not IsEmpty(subkeys) Then
    GPOMachine = subkeys(LBound(subkeys)) 
    GPOUser    = subkeys(UBound(subkeys))
 
    RegCopyTree HKEY_CURRENT_USER, strKeyPath & GPOMachine & strStandardPath, strKeyPath & GPOMachine & strDomainPath, False
  Else
    WScript.Echo "Policy not found, please try editing the policy manually"
  End If
Else
  WScript.Echo "Please start editing the Group Policy before running this script"
End If

The code here is the shell of the script. We need to flesh out the functions keyExists, GetSubkeys, RegCopyTree, and valueExists (which we can’t see just yet). So first we will have a look at keyExists:

Function keyExists(Hive, Key)
  On Error Resume Next
  Err.Clear
 
  ret = objReg.EnumValues(Hive,Key,arrValues,arrValueTypes)
 
  If ret <> 0 Then
    keyExists = False
  Else
    keyExists = True
  End If
  Err.Clear
  On Error Goto 0
End Function

Fairly straightforward, we try and enumerate the values of a key. If we succeed then the key does exist, otherwise it doesn’t. We will use the same principle for checking if a Value Exists.

Function valueExists(Hive, Key, ValueName)
  On Error Resume Next
  Err.Clear
 
  valueExists = False
  If Not keyExists(Hive, Key) Then
    Exit Function
  End If
 
  ret = objReg.EnumValues(Hive,Key,arrValues,arrValueTypes)
 
  If IsNull(arrValues) Then
    Exit Function
  End IF
 
  For i = LBound(arrValues) to UBound(arrValues)
    If LCase(CStr(arrValues(i))) = LCase(CStr(ValueName)) Then
	  valueExists = True
	  Exit Function
	End If
  Next
 
  valueExists = False
 
  Err.Clear
  On Error Goto 0
End Function

Here, we take the Enumeration of the Keys Values a step further and actually step through them looking for a match with ValueName. I have opted for a Case Insensitive search due to registry being case insensitive with value names.

Function GetSubkeys(Hive, Key)
  On Error Resume Next
  Err.Clear
 
  ret = objReg.EnumKey(Hive,Key,arrSubkeys)
 
  GetSubkeys = arrSubkeys
 
  Err.Clear
  On Error Goto 0
End Function

Possibly the simplest of the functions, GetSubkeys just returns an array of Keys underneath the current Key. The most indepth function we require is the RegCopyTree:

Function RegCopyTree(Hive, SrcKey, DestKey, Force)
  On Error Resume Next
  Err.Clear
  strComputer = "."
  Set StdOut = WScript.StdOut
  strValue = ""
  If Force <> True Then
    Force = False
  End If
 
  if Right(SrcKey,1) <> "\" Then SrcKey = SrcKey & "\"
  if Right(DestKey,1) <> "\" Then DestKey = DestKey & "\"
 
  ret = objReg.EnumValues(Hive,SrcKey,arrValueNames,arrValueTypes)
 
  For i= LBound(arrValueNames) To UBound(arrValueNames)
    'StdOut.WriteLine "Value Name: " & arrValueNames(i) 
	StdOut.WriteLine "Copying from: " & SrcKey & arrValueNames(i)
	StdOut.WriteLine "To          : " & DestKey & arrValueNames(i)
    StdOut.Write     "       Value: "
 
	If (Not valueExists(Hive, DestKey, arrValueNames(i))) Or Force Then
	  Select Case arrValueTypes(i)
			Case REG_SZ
				'StdOut.WriteLine "Data Type: String"
				'StdOut.WriteBlankLines(1)
				
				objReg.GetStringValue Hive, SrcKey, arrValueNames(i), strValue
				objReg.SetStringValue Hive, DestKey, arrValueNames(i), strValue
				StdOut.Write strValue
			Case REG_EXPAND_SZ
				'StdOut.WriteLine "Data Type: Expanded String"
				'StdOut.WriteBlankLines(1)
				
				objReg.GetExpandedStringValue Hive, SrcKey, arrValueNames(i), strValue
				objReg.SetExpandedStringValue Hive, DestKey, arrValueNames(i), strValue
				StdOut.Write strValue
 
			Case REG_BINARY
				'StdOut.WriteLine "Data Type: Binary"
				'StdOut.WriteBlankLines(1)
				
				objReg.GetBinaryValue Hive, SrcKey, arrValueNames(i), strValue
				objReg.SetBinaryValue Hive, DestKey, arrValueNames(i), strValue
				For Each x in strValue
		          StdOut.Write Hex(x) & " "
		        Next
 
			Case REG_DWORD
				'StdOut.WriteLine "Data Type: DWORD"
				'StdOut.WriteBlankLines(1)
				
				objReg.GetDWORDValue Hive, SrcKey, arrValueNames(i), strValue
				objReg.SetDWordValue Hive, DestKey, arrValueNames(i), strValue
 
				StdOut.Write Hex(strValue)
			Case REG_MULTI_SZ
				'StdOut.WriteLine "Data Type: Multi String"
				'StdOut.WriteBlankLines(1)
				
				objReg.GetMultiStringValue Hive, SrcKey, arrValueNames(i), strValue
				objReg.SetMultiStringValue Hive, DestKey, arrValueNames(i), strValue
				For Each x in strValue
		          StdOut.Write x
		        Next
		End Select 
 
		StdOut.WriteLine ""
    End If '' Force
  Next
 
  ret = objReg.EnumKey(Hive,SrcKey,arrSubkeys)
 
  For i = LBound(arrSubkeys) to UBound(arrSubkeys)
    If Not keyExists(Hive,DestKey & arrSubkeys(i)) Then
	  objReg.CreateKey Hive,DestKey & arrSubkeys(i)
	End If
	RegCopyTree Hive, SrcKey & arrSubkeys(i), DestKey & arrSubkeys(i), Force
  Next
 
  On Error Goto 0
End Function

This function takes the Hive, Source Key, Destination Key, and a Boolean Value to determine whether to Force overwriting existing values. It first creates the Destination key if it doesn’t already exist, then enumerates all values in the Source path, and writes them to the Destination path, creating new values or overwriting only if Force is set. This function has a lot of StdOut.Write calls to show the progress of the duplication. Running the script via CScript gives the following results:

Copying from: Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{678C8897-54AA-4FB9-AA72-6C227C287D12}Machine\Software\Policies\Microsoft\WindowsFirewall\StandardProfile\EnableFirewall
To          : Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{678C8897-54AA-4FB9-AA72-6C227C287D12}Machine\Software\Policies\Microsoft\WindowsFirewall\DomainProfile\EnableFirewall
       Value: 1
Copying from: Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{678C8897-54AA-4FB9-AA72-6C227C287D12}Machine\Software\Policies\Microsoft\WindowsFirewall\StandardProfile\AuthorizedApplications\Enabled
To          : Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{678C8897-54AA-4FB9-AA72-6C227C287D12}Machine\Software\Policies\Microsoft\WindowsFirewall\DomainProfile\AuthorizedApplications\Enabled
       Value: 1
...

This should simplify the time taken for duplicating from Standard to Domain profile. For future reference this has also made it far easier to import/export port/program exceptions from policies I am editing. In future I may incorporate this into my Group Policy Firewall Exceptions Excel Spreadsheet in VBA to allow writing updated policies to the Policy.

After running this the settings will be seen to have changed in the Group Policy Editor Window immediately. I have tested this and checked that the Logging file is not replaced by “…\standard.log” where it should be “…\domain.log”.

Cheers, Chris.

Attached: RegFirewallProfileDuplication.vbs

After quite some time looking in to how to achieve my goal I came up with a rather simple, yet ultimately hacky, solution. Give the SYSTEM Account Administrative Privileges.

It turns out that the SYSTEM Account, despite not having Administrator level permissions, does have permission to modify group memberships. As such I came up with two functions to manage these permissions for itself:

'*****************************************************************
' Elevates the System Account to a Member of the Administrators Group
Function ElevateSystem
  strSystemUser = "WinNT://NT AUTHORITY/SYSTEM"
  Set objGroup = GetObject("WinNT://./Administrators,group")
  If Not objGroup.isMember(strSystemUser) Then
    objGroup.Add (strSystemUser)
  End If
End Function
 
'*****************************************************************
' Removes the System Account from the Administrators Group
Function RelegateSystem
  strSystemUser = "WinNT://NT AUTHORITY/SYSTEM"
  Set objGroup = GetObject("WinNT://./Administrators,group")
  If objGroup.isMember(strSystemUser) Then
    objGroup.Remove (strSystemUser)
  End If
End Function

I just run ElevateSystem at the start of the script and then RelegateSystem at the end of the script and I have no issue with permissions anymore.

Elegant, yet hacky. Hope somebody found this useful, because it sure beats creating (and then managing) a new Administrator User on thousands of Workstations.

N.B. I should also point out that if you are installing a script onto Workstations that you will be using this kind of workaround on, make sure you set the permissions on it. The last thing you need is somebody hijacking your script to do whatever they want with Administrative Privileges.

Cheers, Chris.

Function StageAllUsers(DomainFQDN, strDomain)
   ' Enumerate all users that are Local and not built in accounts.
   strComputer = "."
   Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
   'Enumerate users where the User Domain is the Local Machine
   Set colItems = objWMIService.ExecQuery _
                  ("Select * from Win32_UserAccount " & _
                   "Where Domain = '" & GetComputerName & "' " & _
                   "And Disabled = FALSE And Name <> 'Administrator'")
   ' Stage each user
   For Each objItem In colItems
      ' Ensure the account actually has a profile (otherwise we can ignore it)
      If GetLocalUserProfile(objItem.Name) <> "" Then
         ret = StageUser(objItem.Name, DomainFQDN, strDomain)
      End If
   Next
End Function

The functions called here are GetComputerName, which returns the name of the local machine, and the other important ones are GetLocalUserProfile and Stage User. The first we can check is GetLocalUserProfile.

'Gets the Profile Path for the User passed in UserName.
' This requires the profile to exist on the local machine
' Returns an empty string on error
Function GetLocalUserProfile(UserName)
   On Error Resume Next
   GetLocalUserProfile = ""
   SDDL = GetLocalUserSDDL(UserName)
   If SDDL = "" Then
      Exit Function
   End If
   Set objShell = CreateObject("WScript.Shell")
   GetLocalUserProfile = objShell.ExpandEnvironmentStrings( _
                            objShell.RegRead( _
                               "HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\" & _
                               SDDL & _
                               "\ProfileImagePath"))
  On Error Goto 0
End Function

The registry path (including the SDDL, covered next) returns the profile path for the user. This relies on a function called GetLocalUserSDDL which goes as follows:

Function GetLocalUserSDDL(UserName)
   strComputer = "."
   Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
   'Enumerate users where the User Domain is the Local Machine
   'and the username matches the Supplied Name
   Set colItems = objWMIService.ExecQuery _
                     ("Select * from Win32_UserAccount  " & _
                      "Where Domain = '" & GetComputerName & "' " & _
                      "And Name = '" & UserName & "'")
   GetLocalUserSDDL = ""
   For Each objItem In colItems
      'Get the first returned SID/SDDL then exit
      GetLocalUserSDDL = objItem.SID
      Exit Function
   Next
End Function

This reads the SDDL (eg S-1-5-21-791012361-4073638415-1907800938-1006 or otherwise known as the String SID) for the User on the local machine. The next major function is Stage User:

Function StageUser(UserName, DomainFQDN, strDomain)
   Set objShell = CreateObject("WScript.Shell")
   ' Not Assuming "C:\Documents and Settings\" & UserName:
   '   Get SDDL of user via WMI interrogation of UserAccount
   '   Get Profile Location of user (from HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\" & SDDL & "ProfileImagePath"
   strProfile = GetLocalUserProfile(UserName)
 
   ' Set ACLs on ProfileLocation
   ret = objShell.Run("subinacl /subdirectories """ & strProfile & """ /grant=""" & UserName & "@" & DomainFQDN & """=F",0,True)
 
   ' Set ACLs on D:\UserData\%username%
   ret = objShell.Run("subinacl /subdirectories ""D:\UserData\" & UserName & """ /grant=""" & UserName & "@" & DomainFQDN & """=F",0,True)
 
   ' Reg load ProfileLocation\NTUSER.DAT into HKU\%username%
   ret = objShell.Run("reg load ""HKU\" & UserName & """ """ & strProfile & "\NTUSER.DAT""" ,0,True)
   ' Reg load ProfileLocation\Local Settings\Application Data\Microsoft\Windows\UsrClass.DAT into HKU\%username%_Classes
   ret = objShell.Run("reg load ""HKU\" & UserName & "_Classes"" """ & strProfile & "\Local Settings\Application Data\Microsoft\Windows\UsrClass.DAT""" ,0,True)
 
   'Try both of the following. One should fail, the other should pass.
   ' Set ACLs on HKU\%username%
   ret = objShell.Run("subinacl /subkeyreg ""HKEY_USERS\" & UserName & """ /grant=""" & UserName & "@" & DomainFQDN & """=F",0,True)
   ' If User is already logged in then the registry will be open at HKU\SDDL
   ret = objShell.Run("subinacl /subkeyreg ""HKEY_USERS\" & GetLocalUserSDDL(UserName) & """ /grant=""" & UserName & "@" & DomainFQDN & """=F",0,True)
 
   'Try both of the following. One should fail, the other should pass.
   ' Set ACLs on HKU\%username%
   ret = objShell.Run("subinacl /subkeyreg ""HKEY_USERS\" & UserName & "_Classes"" /grant=""" & UserName & "@" & DomainFQDN & """=F",0,True)
   ' If User is already logged in then the registry will be open at HKU\SDDL
   ret = objShell.Run("subinacl /subkeyreg ""HKEY_USERS\" & GetLocalUserSDDL(UserName) & "_Classes"" /grant=""" & UserName & "@" & DomainFQDN & """=F",0,True)
 
   ' Reg unload HKU\%username%
   ret = objShell.Run("reg unload ""HKU\" & UserName & """",0,True)
   ' Reg unload HKU\%username%_Classes
   ret = objShell.Run("reg unload ""HKU\" & UserName & "_Classes""",0,True)
 
   ' Get Domain User SID from ProfileLocation ACL
   arrSID = GetDomainUserSidFromFolderACL(strProfile, UserName, strDomain)
 
   If UBound(arrSID) > 0 Then
      ' Convert Domain User SID to SDDL
      WScript.Echo "Getting Sid for " & UserName
      SDDL = ArraySidToStrSid(arrSID)
 
      ' Stage Domain User Profile into Registry under HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\%DomainUserSDDL%
      ret = CreateAndLinkProfile(SDDL, arrSID, strProfile)
   Else
      'Account didn't exist in the domain or ACL failed to set on Folder
   End If
End Function

For the most part this function behaves by running external commands to mount registry hives, and set ACLs on folders and registry, all up until we call GetDomainUserSidFromFolderACL. This is where we retrieve the SID of the Domain User that we are pre-staging via the ACL we set earlier on the Local User Profile folder. This subverts the need to query Active Directory for the SID through other means.

Function GetDomainUserSidFromFolderACL(strFolder, strUserName, strUserDomain)
   Dim arrSID(0)
   GetDomainUserSidFromFolderACL = arrSID
 
   Set objFSO = CreateObject("Scripting.FileSystemObject")
   If Not objFSO.FolderExists(strFolder) Then
      Set objFSO = Nothing
      Exit Function
   End If
 
   ' Ensure that strFolder is of the form C:\\Documents and Settings\\UserName
    strFolderName = Replace(strFolder, "\\","\")
    strFolderName = Replace(strFolderName, "\","\\")
 
   Set wmiFileSecSetting = GetObject( _
      "winmgmts:Win32_LogicalFileSecuritySetting.path='" & strFolderName & "'")
 
   RetVal = wmiFileSecSetting. _
       GetSecurityDescriptor(wmiSecurityDescriptor)
   If Err <> 0 Then
       Exit Function
   End If
 
   ' Retrieve the DACL array of Win32_ACE objects.
   DACL = wmiSecurityDescriptor.DACL
 
   For each wmiAce in DACL
   ' Get Win32_Trustee object from ACE 
      Set Trustee = wmiAce.Trustee
      If (StrComp(Trustee.Name, strUserName, vbTextCompare) = 0) And _
         (StrComp(Trustee.Domain, strUserDomain, vbTextCompare) = 0) Then
         GetDomainUserSidFromFolderACL = Trustee.SID
         Exit Function
      End If
   Next
End Function

Although this subverts the need to Query Active Directory, this does also mean that we receive the SID in a format that is unexpected. Normally, via querying Active Directory we would have received a SID in an Octet String format. Querying the SID from WMI returned it in SDDL or String SID format. The format that we receive the SID from the ACL is in an Array of Integers. In order to Pre-stage an account we need the SDDL/String SID, and the only way to get this in VBScript is to manually convert it using some functions developed by Richard Mueller and Wilfred Wong in this newsgroup posting.

Instead of using only the code listed, we need to alter it for dealing with the SID array we received back from the ACL.

Function ArraySidToStrSid(arrSid)
   ' Function to convert OctetString (byte array) to Decimal string (SDDL) Sid.
   Dim strHex, strDec
 
   strHex = ArraySidToHexStr(arrSid)
   strDec = HexStrToDecStr(strHex)
   ArraySidToStrSid = strDec
End Function
 
Function ArraySidToHexStr(arrSid)
   ArraySidToHexStr = ""
   For Each x In arrSid
      ArraySidToHexStr = ArraySidToHexStr & _
         Right("0" & Hex(x), 2)
   Next
End Function

The HexStrToDecStr function is the same as it was from the Richard Mueller posting listed above.

Finally we just need to run through the actual staging of the account:

Function CreateAndLinkProfile(strNewSDDL, strNewSID, strProfilePath)
   WScript.Echo "Creating Profile for " & strNewSDDL & ": " & strProfilePath
   'Write Sid to registry
   ret = WriteRegBinaryToRegistry(HKEY_LOCAL_MACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\" & strNewSDDL,"Sid",strNewSID)
   ret = WriteRegStringToRegistry(HKEY_LOCAL_MACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\" & strNewSDDL,"ProfileImagePath",strProfilePath)
   ret = WriteRegStringToRegistry(HKEY_LOCAL_MACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\" & strNewSDDL,"CentralProfile","")
   ret = WriteRegDwordToRegistry(HKEY_LOCAL_MACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\" & strNewSDDL,"Flags",1)
   ret = WriteRegDwordToRegistry(HKEY_LOCAL_MACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\" & strNewSDDL,"State",0)
End Function

At this point if the Domain User logs in they get redirected to the existing local users profile. Then if rollback is initiated they log on with the Local User account with the same profile. This is seamless to end users, both forward and backward.

On a side note the functions for writing to the registry are through WMI due to needing to write Binary values to the Registry

Function WriteRegBinaryToRegistry(Hive, strKeyPath, strValueName, ArrValues)
   strComputer = "."
   Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
               strComputer & "\root\default:StdRegProv")
   oReg.CreateKey Hive,strKeyPath
 
   oReg.SetBinaryValue Hive, strKeyPath, strValueName,ArrValues
End Function
 
Function WriteRegDwordToRegistry(Hive, strKeyPath, strValueName, Value)
   strComputer = "."
   Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
               strComputer & "\root\default:StdRegProv")
   oReg.CreateKey Hive,strKeyPath
 
   oReg.SetDwordValue Hive, strKeyPath, strValueName,Value
End Function
 
Function WriteRegStringToRegistry(Hive, strKeyPath, strValueName, Value)
   strComputer = "."
   Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
               strComputer & "\root\default:StdRegProv")
   oReg.CreateKey Hive,strKeyPath
 
   oReg.SetStringValue Hive, strKeyPath, strValueName,Value
End Function

Cheers, Chris.

Edit: DomainAccountProfileStaging.vbs has been uploaded as a complete file.

In this process I have come across an array of options in migrating accounts from a Local User account to Domain User account and transferring the profiles across to keep the user “look and feel” that they are accustomed to.

One problem: In this scenario it makes for a very manual rollback strategy, no matter how much scripting and automation is involved in the migration process. This boils down to Novells implementation of “Dynamic Local User” which effectively creates a Local User Account that is not really bound to a User Account in eDirectory for Authentication or mapping purposes (which you can see if you look at the account SIDs).

So, how can you Migrate a local profile to a Domain User account while still maintaining a seamless rollback option (without using Roaming Profiles… This is out of the question)? The solution I have worked on is what I am terming “pre-staging” or “seeding” the Domain User Profile.

1. Enumerate all Local Enabled Users (except for “Administrator”)
2. Get the SID for that User (and the SDDL/String SID)
3. Read the Profile Path for that User from Registry
4. Set an ACL on that folder for <Domain>\<UserName> (we have the UserName being replicated between eDirectory and Active Directory
5. Mount the existing users NTUser.dat into HKU\<UserName>
6. Set ACL on HKU\<UserName> and all subkeys for <Domain>\<UserName>
7. Set ACL on HKU\<LocalUserSID> and all subkeys for <Domain>\<UserName> (just in case the user is actually logged in)
8. Dismount HKU\<UserName>
9. Mount the User Class hive (UsrClass.dat) into HKU\<UserName>_Classes
10. Set ACL on HKU\<UserName>_Classes and all subkeys for <Domain>\<UserName>
11. Set ACL on HKU\<LocalUserSID>_Classes and all subkeys for <Domain>\<UserName> (just in case the user is actually logged in)
12. Dismount HKU\<UserName>_Classes
13. Read the ACL on the Profile Folder (set Earlier) for <Domain>\<UserName> to get the Domain User SID
14. Convert the Domain User SID to an SDDL/String SID
15. Pre-stage/Seed the Domain User Profile by creating a new Registry key in HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\<DomainUserSDDL>
16. Write in a few choice keys, the two most important being ProfileImagePath (String) and Sid (Binary). (The others I seeded were the DWords State and Flags, which were set to 0, and CentralProfile, which was an empty string).

Once the eDirectory user is no longer a member of a DLU enabled User Profile Package, they will be forced to log on through the Active Directory Domain (yes, we are still logging on through the Novell Client). The Profile used for the Domain User will be the same as that used by the Local user. The added benefit is that our rollback strategy becomes “Add user to a DLU enabled User Policy Package” and gets them to log back into their original profile. To safely secure a situation where there is a catastrophic failure of the profile (loss) a backup of the profile can also be done at the seeding stage (just check %userdomain% for equality with %computername% to see if they are logging on with a Local account or a Domain Account).

This has had only minor testing at this stage, but as no paths have changed and there appears to be no problem with the Domain User using the existing Profile I believe this is a reasonably comprehensive solution. This, I must stress, is not a recommended way to deal with migrating users, but it is a tricky little feature that can be abused as I have just demonstrated.

Code (or VBScript) will follow soon

Cheers, Chris.

The past few months have also seen my University Graduation 3 days after my Daughters Birth, Family Visits, Job Applications, Job Interviews, and finally Permanency in my Servers Position.

Aside from that I have been working with some friends on converting the old TA Server to the C# .Net/Python version (PyTA). I have also been busy in mapping out my development goals and objectives for the coming months and years.

David Allens Getting Things Done

In order to better manage my time and my priorities I have been implementing and reviewing David Allen’s “Getting Things Done”, and have been operating my own install of GTD-PHP. I have been using this to manage all aspects of my life, from professional to personal projects. This has allowed me a lot greater control of my personal and professional life and allowed me to manage my time far more effectively than ever before. Currently in this system I am managing 100 Active Projects, 44 Someday/Maybe Projects, and within those I have currently 147 Actions within those. I am still in the process of determining Next actions for some of these projects, but at least having visibility of all these things I need to do has given me greater control of managing the most important of these. Most of the projects without next actions are someday/maybe projects, and the others that are not could be put in someday/maybe until such time as I have time to process their next actions. I definitely encourage anybody to try this method of organisation, time management, prioritisation because it has helped me to lower my stress and be able to switch off from work when I get home. Just note that it does tend to increase the likelihood of adding more projects to your list than you started out doing .

Aside from this I have been attempting to build an Application Audit script at work that will pull the NAL objects from our system through LDAP. I have started coding this type of script now as a class which is in a .vbs file and then for implementing its use I have started using .wsf files to include and execute the required code. This adds to the usability of my existing code and makes my code far more acccessible for reuse in other applications. I had already started writing these types of classes before for my Ini File Handler, but previously I had been including the VBScript files internally using a manual Include function:

Function Include(vbsFile)
   Set fso = CreateObject("Scripting.FileSystemObject")
   If fso.FileExists(vbsFile) Then
      Set f = fso.OpenTextFile(vbsFile)
      s = f.ReadAll()
      f.Close
      ExecuteGlobal s
   End If
End Function

The .wsf include method is so much cleaner:

<script language="VBScript" src="Applications.vbs"/>

When I have managed to get my projects and actions further under control I will have to provide updates. I have some plans for the XNA in a Day series which I started with breakout, but that is some way off. I am also planning on overhauling some of my previous projects and actually actioning them.

Cheers, Chris.

After a rather hectic week of scripting a solution and then distributing it under an excessively short deadline, I have been asked to provide stats on the result of forcing this solution out to clients. The solution that I had to develop keeps tabs on a System Volume Image of PCs, and ensures that this Image never gets out of date too far. Currently I am not forcing a Store every restart, as the planned solution was to do, but I do inform the client that their current Image is out of date and ask them if they want to do a Store now. If they click on Yes then their PC is rebooted and the Store is done (providing that one of many flaws in the current Store process do not interrupt the process).

Because of some of the issues that we have had, as well as Managements want to view the impact of what we have done in a statistical format, I was required to provide a secondary application, which is just an updated version of an AutoIT Script that logs the Image Date into a log file during login. Because this file was preexisting it has been used in this way to gather stats for some time.

The issue is that the log file includes EVERY instance of a login for a PC, and I want only the most recent with the timestamp of the image, not all the other instances, or the log values that are too old (I was unable to clear the logs due to current procedure). Therefore I was required to learn some new things in the VBScript world. This solution is surprisingly fast considering how much data it is required to crunch in order to produce the output CSV file.

Const ForReading = 1
Const ForWriting = 2

Dim arrLines()
i = 0

Set objDictionary = CreateObject("Scripting.Dictionary")
Set objFSO = CreateObject("Scripting.FileSystemObject")

objStartFolder = WScript.ScriptFullNameobjStartFolder = Replace  (objStartFolder, WScript.ScriptName, "") 

Set objFolder = objFSO.GetFolder(objStartFolder & "Logs")

Set colFiles = objFolder.Files
For Each objFile in colFiles
    Set textFile = objFSO.OpenTextFile(objFile.Path, ForReading)

    Do Until textFile.AtEndOfStream
        Redim Preserve arrLines(i)
        arrLines(i) = textFile.ReadLine
        i = i + 1
    Loop

    For i = Ubound(arrLines) to LBound(arrLines) Step -1
        splt = Split (arrLines(i),",")

        If (UBound(splt) < 19) Then
            i = LBound(arrLines)
        Else
            If Splt(19) <> "" Then
               If Not objDictionary.Exists(splt(1)) Then
                  objDictionary.Add splt(1),splt(19)
               End If
            End If
        End If
    Next

    ReDim arrLines(0)
    i = 0
    textFile.Close
Next

Set writeFile = objFSO.CreateTextFile(objStartFolder & "Stores.csv")
For Each strKey in objDictionary.Keys
   writeFile.WriteLine strKey & "," & objDictionary.Item(strKey)
Next
writeFile.Close

In this particular script the splt Array has 20 columns (or 19 for those items that were prior to me updating the script). Column 2 (or splt(1)) is the PC Name, and Column 20 (or splt(19)) is the Timestamp of the Image. This script reads through every file in the Logs folder (in the same path as the script) and reads the file in reverse until it comes across the entries with only 19 columns. For every unique PC Name that it finds it adds this into a Dictionary object with the Timestamp as the value. The Dictionary is then written to the new CSV file one at a time.

In order to get the stats on how effective this has been, I paste a couple of Excel Macros:

=COUNTIF(B:B,">22/08/2008")
=COUNT(B:B)

The magic date here is the 22nd of August 2008. This was chosen purely because it was a recent date, and it was newer than most of the Images for the PCs within the IT Department, who already had the AutoStore scripts working on their machines. Which provided for a controlled Environment for testing some of the modifications I was forced to make last minute.

One thing that I could do to improve the accuracy of this script is to pull out all the Workstation Names from Novell using LDAP and get a total overall status of where the Store dates are across all PCs, but that would pollute the pool with a large number of machines that have been decommissioned (they still appear as a Workstation in Novell until they have not been logged on to for 3 months, then they fall off the system).

On a side note, I have to pull in the Logs into the Logs directory in some way, which is achieved for me by running a Batch file which I have written as follows:

@ECHO OFF
ECHO Pulling Logs %DATE% - %TIME%>>Log.txt
ECHO.>>Log.txt
%~d0
cd %~dp0
FOR /F "tokens=*" %%A IN (Sources.txt) DO (
  FOR /F "tokens=1 delims=" %%Z IN ("%%A") DO (
     COPY "%%AlogsLogIn.csv" "%~dp0Logs%%Z.csv" /A /D /Y /Z >>Log.txt
  )
)
ECHO.>>Log.txt
ECHO Current Stores being Rebuilt at %DATE - %TIME%>>Log.txt
WScript Stores.vbs
Start Excel Stores.csv
ECHO Log Pull Finished at %DATE% - %TIME%>>Log.txt

This script uses a file called “Sources.txt” which is a list of paths on newlines which point to where each of the Logs are stored. Each line consists of something like \ServerNameSYSPUBLIC. The line FOR /F “tokens=1 delims=” %%Z IN (“%%A”) allows me to pull out the servername from each line in the file, so that when I copy the file from the server, I can rename it so that its source can be identified.

I think this will conclude todays lesson in VBScript and Batch, and I’d best get back to studying.

Cheers, Chris.

I have scheduled both of these exams for the same day, which will make the day a very long one. If I manage to pass both then that will give me MCSA: Messaging Specialist status. I can then focus on the remaining 3 exams to get my full MCSE certification.

I hope to get around to completing my Novell CNA exam at some point soon as well. Or once I have the MCSE I might concentrate on the Cisco CCNA. This will give me the required certification level in order to work overseas.

There are still 2 weeks until the exams, so time to start cramming as much study as I can in.

Cheers, Chris.

Trav and I have approached the Server team with an idea on distributing apps more effectively, relying mainly on network addresses of the PCs to correctly locate an application server. This brings up a few logistical hurdles.

1. The restructuring of our Applications such that we can point to a mapped network drive instead of relying on UNC paths.
2. The fact that some applications are released with site specific information. As we currently have to modify every new release of these apps to include that information, we should approach the issue from a more managable perspective.
3. The Implementation of Login Scripts to Base Drive Mapping on current Network Location instead of the Current Login or Workstation Context or Group (as this then provides a benefit of decreased WAN traffic for Mobile Computers and Distributed Applications).
4. The Politics of testing and gaining approval for implementing a new process into something that is seen as a working system. This is possibly the greatest hurdle to overcome in regards to the push for initiative.

At least with respect to point Number 4, Trav and I raised this with one of our counterparts in the Server Team, and although we were given some good reasons why some of the ideas we initially had could not go any further than the drawing board, he did provide some additional ideas on how to proceed to at least implement some positive change so that we can all manage our site specific apps (Point number 2) more effectively.

The thing we need to concentrate on first is going to be appropriating some hardware and then building an environment in which we can test some of our theories that are not being implemented. In the mean time I will start testing some of the ideas that the team has approved at this point.

Hopefully we can implement a ZfS Server that creates NALs under the District Container (as opposed to our site containers) which uses %DEST-APPS1% as X:\ instead of a UNC path, and use a Cluster Wide Login Script to appropriately map X:\.

One parting thought on another issue this could have on us, that the X:\ drive is not consistent around the state. From ZfS’s perspective, everything is all well, however there are a lot more things stored on the X:\ drive that are used constantly from a Technical perspective. This will possibly require some more training, or at least another drive mapping…

Until I start looking into DFS at least

In three weeks time we shall see what position I am in though, before too many things are set in stone.

Cheers, Chris.