It is a common practice amongst administrators to disable the creation of short filenames on NTFS. I freely admit to have recommended this in the past. Was I wrong? Background

Choosing a domain name that will only be visible from an internal network may look simple. Unfortunately, it is not. The basic problem: How to avoid collisions between the internal namespace and the internet?

My New Book is Out: Windows Server 2008 Command Line ReferenceThe command line is a powerful tool. Many a tedious task can be offloaded to a cleverly written script. Scripts and batch files, however, are like tool boxes without too many tools (which relates more to batch files than scripts). To become truly powerful, the boxes must be filled. That is what my reference book is all about.

From time to time the question gets asked how a batch file or console program can be executed silently or hidden, i.e. without a console window popping up. If you do not know what I am talking about: press Win+R, type “help” and press ENTER. A black console window will open, execute the HELP command and close again. Often, this is not desired. Instead, the command should execute without any visible window.

A few weeks ago I published the tool ParseCitrixLicense which displays the contents of Citrix license files in a human-readable form. The original version 1.0 did not support XenDesktop licenses, for the simple reason that I had none to test my program with. Recently my colleague Nicholas Dille provided me with a XenDesktop eval license which I used to implement the missing tags in ParseCitrixLicense. Please see for yourself what ParseCitrixLicense extracts from a XenDesktop license file.

With the release of the hotfixes KB946633 and PSE450R02W2K3037 ClearType font smoothing is finally available on both the current and the upcoming Citrix flagship products Presentation Server 4.5 and XenApp 5.0. Remains the question of how to configure it.

It took five years and probably lots of customer complaints, but finally one of the most important technologies introduced with XP/Server 2003 is available over the remoting protocols RDP and ICA: font smoothing aka ClearType.

I will make a bold statement here: corrupt user profiles are a myth. That may seem very bold indeed, with 331,000 hits on Google for “corrupt user profile” and countless admins complaining about having to deal with corrupt profiles on a daily basis.

Update: Version 1.1 supports XenDesktop Licenses in Addition to XenApp Licenses Most Citrix products rely heavily on license files. While the basic format of a license file is somewhat documented, most fields used in license files are not. This makes understanding their contents difficult. It does not help that the license files can hardly be called readable with most of the relevant data in one long line.

While working on the next edition of my book I found several documentation errors on Microsoft’s Technet pages describing the command line tools of Windows Server 2008. One of the graver errors relates to clustering.

A recent discussion with a colleague brought this topic to my attention which I have not discussed in detail in my series on Windows x64: Memory scalability of 32-bit Terminal Servers

Much has been written about the many new features of Windows Server 2008 Terminal Services. Now, with the upcoming release of Citrix XenApp 5.0 (Project Delaware), Citrix updates its best-selling product and ports it to the new platform. Brian Madden analyzes whether it is still worth buying Citrix XenApp / Presentation Server on top of pure Windows Terminal Services.

Recently I got into a very interesting discussion with my colleague Nicholas Dille on various aspects of Windows x64. One question he brought up was especially intriguing: knowing about registry redirection, it is not astonishing to find that the 32-bit version of the registry key HKLM\Software\Classes (aka HKCR) gets to be HKLM\Software\Classes\Wow6432Node. But there is also HKLM\Software\Wow6432Node\Classes!? How can there be two different Wow6432Node 32-bit keys for one 64-bit key?

This is the seventh part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the last article I explained that mixed 32-/64-bit processes are not allowed and how that rule affects both administrators and script-writers. In this context I mentioned the strangely named directory SysWOW64. Today I am going to explain what it is used for by starting with redirection.

This is the sixth part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the last article I discussed how 32-bit applications are wrapped up in the WoW64 subsystem. Today we will take a deeper look at some limitations of 64-bit Windows and what they mean in practice.

This is the fifth part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the last article I explained that the 64-bit OS can only load 64-bit drivers. Today we will turn our attention to user-mode code and analyze how the move to x64 affects downlevel applications.

This is the fourth part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the last article I wrote about the changes to the x86 processor architecture that make x64 possible. But there is of course more to a new platform than just updated hardware.

This is the third part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the first two articles (here and here) I explained key concepts and limitations of the x86 platform: every 32-bit process can use 2 GB of address space, which is by far enough for most applications. However, the kernel is also limited to 2 GB of RAM, which can lead to bottlenecks on systems that need to keep track of large amounts of resources, which is typically the case on terminal servers.

This is the second part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the first article I explained key concepts of the x86 platform, namely that user-mode processes each get 4 GB of virtual address space, but can use only half of it, because 2 GB are used for the operating system kernel.

I will start the new year with a small series on Windows x64 in which I will explain why 64-bit computing is not only necessary but inevitable. I will then go on to explain in detail where Windows x64 differs from the 32-bit versions and what that means for all those who are responsible for the design, operation, and support of 64-bit systems. All the while I will be focusing on terminal servers, but most facts and conclusions are valid for other system types, too.

Recently a colleague of mine had a problem: by mistake he had deleted part of the software registry hive (HKLM\Software) of his Vista machine while trying out some code. When he asked me for help my first thought was to go back to the last System Restore point. But that seemed a bit harsh. It would have restored the registry settings in question. But not only that: System Restore not only captures and restores every single file in the windows directory, it also does that same for a lengthy list of file types on all volumes for which System Restore is enabled.

Some time ago I wrote about a misconception so common that it might pass as an IT legend - the confusion of HKU\.Default with the default user’s registry hive. Recently I came across another interesting misapprehension. As you know, the profiles base directory (usually C:\Documents and Settings) contains not only one special sub-folder, Default User, but also All Users, whose purpose is well-known: When Explorer builds the start menu and the desktop it pulls entries both from the logged-on user’s profile and from the all users folder. That is, by the way, the reason why standard users (i.e. non-admins) cannot modify some of the icons on the desktop and in the start menu - those that reside in the All Users folder, which is writeable only for administrators.

I confess: I like group policies. They are and have always been a great way of managing computer and user settings ever since their conception and introduction with Windows 2000. Of course, at the beginning management tools were nonexistent. But we were so happy not to have to rely on NT4’s system policies any more that we did not even notice. Then came GPMC, and life started to become truly great. RSOP! Group Policy modelling! Those are great tools for every admin!

I recently had the requirement to refresh the Windows desktop after certain changes had been made to Explorer’s registry entries. This seems simple at first: klick on any item on the desktop and then press F5. It wasn’t, though. The registry changes would be made upon logon by a software installation agent. It was expected by the customer that the end user see the the effects of the change immediately without any user intervention. That sent me hunting for a solution on the internet. I came across many forum posts that showed that many others already had exactly the same requirement. Interestingly, none of the proposed solutions actually worked. Except for one, which I found at last.