Tag: Windows XPe

Windows XP(e) refusing to connect to a terminal server

Christian Leave a comment

Today a error message reappeared I thought I wouldn’t see again. We use Wyse Thin Clients and 2X running on two terminal servers, to provide the thin clients with applications. Now, once a while one of the thin clients (not all at once, just a single one) refuse to connect to the terminal server jabbing about this:

The error message you get from the 2X client ain’t the slightest bit more helpful.

I remember the solution being not so trivial with the thin clients. As it turns out, Microsoft does have a solution for that kind of problem.

“Simply” open up the registry, and clean out HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSLicensing. That is the place where the remote desktop client saves the obtained terminal server licensing key.

GPO (behind the scenes)

Christian Leave a comment

Well, to begin with we had this really weird problem that the thin clients as well as the terminal server would only load user based group policy if you are a member of the group of local administrators. While that’s ok for the thin clients (users can’t actually change something unless they log in as “Administrator” – don’t ask me why), it’s a real no-no on the terminal server.

We tried redoing *everything* (that is, starting with the domain, then terminal server and after that the thin clients) and yet nothing changed, it didn’t work either. That’s what I’ve been doing the last 2 weeks. Up till now, I always thought a user would have access to the ntuser.dat (that is HKEY_CURRENT_USER), if his NTFS permissions would be correct. But nooooooooooooooooooooo, Microsoft had to introduce another layer of permissions.

Old permissions on HKEY_CURRENT_USER
Old permissions on HKEY_CURRENT_USER
Once you change it to be proper (as in remove the dead user entry and add a group that actually gets you somewhere), it’s all starting to work!

New permissions on HKEY_CURRENT_USER
New permissions on HKEY_CURRENT_USER

Windows XP Embedded, Windows Server 2003 and GPO settings (the solution)

Christian Leave a comment

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_USERSoftwarePolicies, 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!

Windows XP Embedded and GPO settings (continued)

Christian 1 Comment

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:

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*

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*

Windows XP Embedded and GPO settings

Christian 3 Comments

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.“

Integrating Windows XPe into Active Directory

Christian Leave a comment

As the guys over at FreeWyseMonkeys demonstrated with JoinDomain.zip, it ain’t hard to integrate a Windows XP Embedded system into Active Directory.

You basically need this:

  • A system powered by Windows XP Embedded
  • netdom.exe (from any Windows XP – SP2 in your MUI language)
  • some know-how, on how to use netdom to integrate it into your AD

Everything else is already present on the Windows XP Embedded systems I’ve seen. Then let’s get it on !

First, copy over the netdom.exe to your XPe, and then run the following command:

Here as a note:

  • ud and pd is a User/Password inside your Active Directory with the permissions to create new computer accounts
  • uo and po is a User/Password with administrative rights on the Windows XP Embedded device

After that, you just need to reboot, Et Voilà! the system is present in your Active Directory. Just be aware, if you’re using a localized Windows XP Embedded by Wyse, make sure to contact your fellow Wyse Support, as the is a bug with the MUI stuff needed for the domain logon.

Also, as yet-another side note: The default Administator password is mentioned in this Knowledge Base entry.

VBscript & Active Directory and printers ? (continued)

Christian 1 Comment

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.

But even that doesn’t work all the time, I still have to figure out why.

Customizing Thin Clients

Christian Leave a comment

As some of you know, the company I’m currently working for, recently acquired some thin clients to replace our old computers for the students to work on. Those PC’s are like P3 800 MHz with 512MB RAM and sadly don’t run Office 2007 anymore, so we replaced them with thin clients and are streaming those applications from a Windows Terminal Server cluster (created by and with 2X Application LoadBalancer).

So far so good, getting them to display the applications ain’t hard, the real hard part starts when you want additional things from this Windows XPe (Embedded), like lets say getting them to display a German language.

First thing is, the management software for those terminals (Wyse Device Manager or WDM) uses it’s own scripting language (with pseudo abbreviations like DF or MR – Delete File and Merge Registry – get it ?), which control the whole distribution of “packages“.

That ain’t necessarily a bad thing, it’s just an additional “language” you need to understand/learn. The initial threshold is rather low (it ain’t no C++ or C#) as it’s just a pseudo language, you just need to make sure you do things in a certain order (like use the auto login registry entry with a new administrator password *after* you changed the administrator password).

We had a lot of work at the beginning of the week (like getting all packages working), and I think we managed finishing all of them (besides some default icon foo, for which is plenty of time when them terminals are already in use).

Thin clients

Christian Leave a comment

As some of you people know, we (as in the University) recently purchased some Thin Clients in order to replace some oldish’ computers and solve the software management at the same time.

The Thin Clients ain’t bad, they are Wyse V90L‘s and they (as in Wyse) use their own management software to manage and deploy those thin clients and software. The bad thing about that, is it’s using it’s own “Scripting Language” (if you can call it that way – it’s more pseudo scripting since you can’t do much with it besides some basic actions).

The Wyse Device Manager also introduces it’s own limitations. Up till now our DHCP had server options for thin clients in some other facility and thus was sending those to *all* subnets it’s acting on, thus overwriting (or disabling ?) the DHCP ACK send out by the WDM. But that’s only one.

The second one is that the WDM seems to use (or expect) the American date format internally. But how did I stumble upon that ? As you know, I’m living and working in Germany and we use a different time/date format than the American’s. Now, lets assume you want to deploy packages to you Thin Clients when no one’s using them anymore (like say – around midnight), you drag your package upon the devices and select “Specific Date/Time“. Now if you have the German date/time format, the WDM will simply tell you, “Deployment date can’t be less than the current system time.”

Initially I was like *WTF*, didn’t I just enter a time in the future (~15 minutes in the future from where we at right now) ?

First I looked through their Knowledgebase, but as nothing was documented there, I called their Support Hotline, where I briefly told ’em what was going on and he immediately told me, that’d I was hitting that error, since the WDM *is* using _and_ expecting the American time/date format internally. But he told me that they’ll hopefully fix that with the next release since they get asked that quite often.