My colleague Jacques Bensimon sent over a great description on the Terminal Server Aware flag and it’s impact on the use of Microsoft’s Terminal Server shadow keys (HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software) which we use extensively for user profile manipulation.
I’ve noticed more and more applications that seem to ignore the Terminal Server “shadow keys” and I thought I’d clue you into what’s going on and how to determine whether a given app will or will not “honor” the shadow keys when it looks for a missing HKCU\Software\... registry entry. Actually, I’ll save myself a lot of preliminary explanation by providing the following link to an AutoHotkey forum article I posted a while back when the author, without fully appreciating the consequences, set the so-called “Terminal Server Aware” flag in AutoHotkey and all “compiled” AutoHotkey programs: (he was nice enough to quickly fix it after I posted my concerns – the post by the way can serve as a nice refresher on what Install Mode and Execute Mode actually mean). The quick summary is that an executable that has this flag in its header is no longer subject to the normal “Execute Mode” behavior that looks for missing HKCU\Software\... entries in the shadow keys and redirects INI file requests from the system’s Windows directory (%SystemRoot%) to the user’s private Windows directory (%HomeDrive%%HomePath%Windows).
Now that you’re back from reading the article ;), I’ll add my suspicion that, in line with my recent comments about
imbecilefledgling programmers now being empowered to write application software with dumbed down versions of Visual Studio, many programmers probably check the “Terminal Server Aware” box when compiling their apps in the mistaken belief that this in and of itself somehow makes their application TS-compatible (when in fact it is supposed to be a signal to Windows that the app has been explicitly written in a such a way as not to need the help of the system to provide default HKCU settings via the Shadow Keys and that it doesn’t use INI files in the Windows directory). Anyway, you might be interested to know that, for example, Word and Excel 2007 do *not* have the TS-aware flag set (so shadow key trickery should still work with those apps) whereas PowerPoint and Outlook 2007 *do* have the flag set and therefore will completely ignore shadow key entries.How do you figure out if an application has the Terminal Server Aware flag set? There is a tool called “MiTeC EXE Explorer” that gives all kinds of info about executables (not just EXEs but also DLLs etc). When you open an EXE in this program (see screenshot of PowerPoint 2007 below), click on the “Header” tab in the top section, then in the “Optional” tab in the bottom section, and look for the “DLL characteristics” hex value: if it’s greater than or equal to 0x8000, then the TS-aware flag is ON (0x8000 is the TS-aware flag bit) – in the screenshot you see that PowerPoint 2007 has the flag value 0x8040, so it does have that flag as I mentioned earlier. When you come across an app like that, you’ll have to find some other way to distribute user settings than the shadow keys (profile, GPP, script, etc – actually, in the case of Office 2007, there is another mechanism available that’s “beyond the scope” of this note – Hint: see HKLM\SOFTWARE\Microsoft\Office\12.0\User Settings).
Later,
JB





With the holidays approaching, now is the time to start thinking about 2011 goals and 2010 gifts. Why not combine the two and hand out Meeting Tokens this year! 


















This month my company began switching over user email accounts to the Microsoft Business Productivity Online Standard Suite. BPOS for short. Like most organizations, email is probably the most critical application in the environment. Users know almost immediately when mail is not working. Working in a small company with many consultants and no dedicated fulltime IT person, outsourcing the maintenance and management of the Exchange infrastructure to Microsoft made a lot of sense for us. 


I just don’t get it. Why do I need to have a user account and password to access a vendor’s Knowledgebase? What is so important behind that link that you do not want it indexed and searchable by Google (my primary troubleshooting tool)? By not allowing major search engines to access your knowledgebase, you are making it THAT much more difficult for me to resolve issues related to your software. Honestly, if someone doesn’t already own your software, I would imagine that they couldn’t care less about your knowledgebase. And while I am at it, ONCE I actually go through the trouble of registering to get access, your search engine pales in comparison to the options that Google provides to me. If you want to track usage, you don’t need to have actual usernames; use IPs and page views like the 