Posted by Christian in Life
OK, so about an hour (yeah, yeah; I know .. I shouldn’t be working at that time, but it really gave me sleepless nights) ago, I finally figured out why the hell both my Windows XP Embedded thin clients as well as my Windows Server 2003 systems where showing this real *weird* behaviour when applying group policies, or more precise the user based configuration of a group policy.
The inspiration came to me after reading this and taking a look at regedit myself, where I noticed the entry “Permissions” for the first time ever since I’m using regedit. I also noticed, that the regedit permissions seem to be using the same groups, one would assign to NTFS resources.
That said, it really all boils down to the ntuser.dat (which *IS* HKEY_CURRENT_USER). As I created the profile with a different user than I am using it with (basically, I want ~12.000 users to use this one profile), I needed to change the permissions *INSIDE* regedit to include a group containing all these users. After that, any user could again merge the settings from ntuser.pol into HKEY_CURRENT_USER\Software\Policies, which in return gives you the joy of your fucking policies working again.
TADAAAAAA! About two weeks worth of work spent for such a shitty thing, and noticing it when you’re off work — priceless!
Posted by Christian in Life
Well, as I said in my previous post, I do have some weird things happening. Apparently adding the domain user to the local group “Administrators” makes everything just works fine, yet he can’t do administrator like stuff (like turning off the write protection, changing local user accounts, …).
Also, if you’re looking for a smart way of how to add a certain global group (as in Active Directory group) to a local group, try this:
NET LOCALGROUP Administrators /ADD DOMAIN\GROUPNAME
That simple, doesn’t even need the usual credentials to lookup the object, it apparently bypassed that step *shrug*.
And yet another weird thing is: if I run a certain command from a deployment script, it gives me different result as a manual execution of said script would give me .. *shrug*
NETDOM JOIN %COMPUTERNAME% /domain:barfoo.org \
/OU:"OU=Thinclients,OU=Computers,DC=barfoo,DC=org" \
/UserD:%ADMIN% /PasswordD:somepass \
/User0: Administrator /Password0:Administrator
NET LOCALGROUP Administrators /ADD BARFOO\Domain-Users
If I put that into a rsp (that is Wyse Device Manager script), it ain’t working. Would I be executing it myself without the WDM, everything works like a charm … *yuck*
Posted by Christian in Life
We’re currently having a weird issue (which we had before); the Windows XP Embedded powering our Wyse V90′s isn’t applying any GPO settings if you log on with a user that has a configured profile.
Googling (is that a valid word yet ?!) for it, only resulted in one useful link, which is apparently a guy with the exact same problem … *shrug* I’m completely out of ideas by now, as I don’t even have a place to start (as in where the reason might be located).
Well, I do have a place to start with (that’s the local Events Viewer), which indeed lists some errors, but only such errors which ain’t making any sense. For example I see this:
- Userenv:1086 – “Windows cannot do loopback processing for downlevel or local users. Loopback processing will be disabled.“
- SceCli:1704 – “Security policy in the Group policy objects has been applied successfully.“
- Userenv:1085 – “The Group Policy client-side extension Folder Redirection failed to execute. Please look for any errors reported earlier by that extension.“
Posted by Christian in Life
As I posted earlier, I tried working around some limitations in Microsoft’s Active Directory by teaching the script some intelligence.
But, since we recently started using Thin Clients, all the stuff I did with the fancy vbs was just a waste-of-time. Turns out, Windows XP Embedded doesn’t work quite the same as a “normal” Windows XP (that’s where I tested the script on), and it simply dies when running the WMI Query. Bollocks.
So I switched back, utilizing a shortcut in Startup, but pointing to the shortened vbs (see below) instead of the ugly batch file someone wrote.
Set WshNetwork = CreateObject("WScript.Network")
WshNetwork.AddWindowsPrinterConnection "\\nas.barfoo.org\Kyocera FS-9100DN KX"
' Set the default printer to something useful
WshNetwork.SetDefaultPrinter "\\nas.barfoo.org\Kyocera FS-9120DN KX"
But even that doesn’t work all the time, I still have to figure out why.
Posted by Christian in Life
Well, since our current solution for mapping printers is an ugly batch file, which needs to be put into Startup, I today poked at doing it in VBscript (I know, but it’s less ugly than the batch script, trust me).
As some of you know, printers are only applicable to users (as in you can’t put a startup script onto an OU, which is going to map the printers). So as we store users and the computes in different OU’s in our Active Directory (we do have about 15.000 students), I can’t apply the printer.vbs to the users OU directly either, unless I implement some intelligence into the script itself.
And that’s basically what I did. Since different pools at the university have different DNS suffixes (like pools.rz.barfoo.org, that our or pools.fmz.barfoo.org) and we only want them students to have our printers when they logon at our pool, I just made the script to get the DNS DomainName of the current active interface and compare it against a given pattern.
' The problem is, if you apply something like this the users get the printers regardless whether they
' are at our location or a different one. So we either need to look up the current AD object (this computer),
' or just compare our current DNS suffix/DomainName against a known pattern.
' Now, lets get the DomainName from the WMI-Interface
strComputer = "."
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colNicConfigs = objWMIService.ExecQuery ("SELECT * FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = True")
For Each objNicConfig In colNicConfigs
strDNSDomain = objNicConfig.DNSDomain
Next
' Apply some regexp foo, to see if we're at the computing center or not!
Dim regexp
Set regexp = New RegExp
regexp.Pattern = "pools.rz.barfoo.org"
if regexp.Test(strDNSDomain) Then
'If so, then lets just connect the printers we need!
Set WshNetwork = CreateObject("WScript.Network")
WshNetwork.AddWindowsPrinterConnection "\\nas.barfoo.org\Kyocera Mita FS-9100DN KX"
' Set the default printer to something useful
WshNetwork.SetDefaultPrinter "\\nas.barfoo.org\Kyocera Mita FS-9100DN KX"
End If