Well, once you thought you don’t have any more problems, another one just pops up. I’m currently bashing my head against the wall, why the hell the forwarded (or is it redirected ?) drives are not shown in the in the “My Computer” explorer view. I pretty sure have an idea why (basically, HKEY_CURRENT_USERSSoftwareClasses isn’t writeable, but that’s where Windows, or rather the Terminal Services — or whatever is creating the associations), just don’t know a clever way around/by it.
It’s basically a dead end. The user has no access to that particular subkey, and I can’t change the permissions by changing it in ntuser.dat apparently. Neither do the inherited permissions apply, so I’m basically stuck. 🙁
As Mike wrote about his experiences with hardware vendors, I’m gonna devote this here post to my favorite software company in the world. We recently bought two copies of a software called “2X Application Server Enterprise Edition“. As one would think from reading the specs of the software, it’s near a Citrix solution (which it is, at least for a small part); but in return it’s faaaar away concerning the price. Just so you get an idea, about what I’m meaning with “faaar“:
Terminal Server CAL:50*17,00
The above are fixed costs, you need them anyway as both Citrix as well as the 2X solution is only working *on top* of Windows Server 2003 Terminal Services.
Now, here’s the real comparison between 2X Application Server & Loadbalancer and Citrix XenApp Platinum Edition:
While 2X is licensed per terminal server, XenApp is licensed per user. As you can see from the above prices, the 2X solution is roughly 1/6 of the Citrix XenApp solution.
As I mentioned before, we decided against the Citrix Presentation Server solution in favour of the 2X LoadBalancer and ApplicationServer combination. You’re gonna say, but Citrix does the same and it’s only one “application frame“. 2X is exactly the same.
I stumbled upon a *real* weird problem. Apparently the terminal server licenses called “per Device” ain’t a real per device. From reading on it Microsoft states it like this:
Device-based versus User-based Terminal Server CALs
Two types of Terminal Server Client Access Licenses are available: TS Device CAL or TS User CAL.
A TS Device CAL permits one device (used by any user) to conduct Windows Sessions on any of your servers.
A TS User CAL permits one user (using any device) to conduct Windows Sessions on any of your servers.
You may choose to use a combination of TS Device CALs and TS User CALs simultaneously with the server software.
If I take the above and take a closer look at my terminal server license server I’ll see something like this:
As you can see, I *do* have devices with more than a single license (in fact, several of them do have more then four), which from my understanding ain’t what Microsoft had in mind.
After noticing this, I initially thought my terminal servers had the wrong license mode, but as you can see below, they are using “per Device“.
Which means, I am completely clueless at this point, as they *really* should be using just a single license, and not multiple ones.
Ok, after experimenting a bit with it, it seems that a license seems to be tied to the SSID. Which would explain, why I see different CAL’s for a single device. We reflashed the thin clients in between (and within that process, the SSID is freshly generated), so that’d be the only explanation I’ve got for what I’m seeing.
Yes, yes. I do list a lot of crappy products (go on, laugh; I don’t really care). Yesterday I had quite a struggle with Microsoft Windows Server 2003 and Terminal services (or more precisely with their way on how to deal with network printers).
As most of you know, there a two (possibly three) different ways on how to do network printers.
would be, to simply share a local connected printer by simply creating a share for the printer
buy a smart printer with integrated print server
a combination of 1. and 2.
We luckily enough do have printers with integrated print servers, so that wouldn’t be a problem. *But* you get a problem if you’re trying to monitor the printer queue if you simply create a new TCP/IP connection from another target. You simply can’t tell who’s printing what.
So we tried to find a way to reuse the already shared printers. And there actually is. Simply create a new local printer (as you would if you’d use the TCP/IP way), but don’t select TCP/IP, select Local Port instead. That’s the whole catch (I’ve been trying to figure that out half the day yesterday). Then simply supply the location (it’s URI formatted like this.is.my.printer.servarYour shady Printer) and click through the dialog.
The only catch with this is, that you have to install any non-standard printer drivers locally. That’s why I tried reusing the already present network drivers, but Windows treats Printers and Network printers differently. The former is treated as a global object (as in visible to all users on the current machine), the latter is only visible to the current user.
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).