In a recent blog post, Mark explains in great detail the file copy process in Vista, why it changed radically from XP and how this impacted real and perceived performance of this basic function. He goes on to explain how some of this has been changed and remedied in Vista Service Pack 1. He makes it clear that some of the code design choices have to be compromises between making things faster in different situations, and that in most cases Vista <> Server 2008 filecopying will be faster using the chosen algorithms than they would be with different choices, or using XP or server 2003 for example.

Copying a file seems like a relatively straightforward operation: open the source file, create the destination, and then read from the source and write to the destination. In reality, however, the performance of copying files is measured along the dimensions of accurate progress indication, CPU usage, memory usage, and throughput. In general, optimizing one area causes degradation in others. Further, there is semantic information not available to copy engines that could help them make better tradeoffs. For example, if they knew that you weren’t planning on accessing the target of the copy operation they could avoid caching the file’s data in memory, but if it knew that the file was going to be immediately consumed by another application, or in the case of a file server, client systems sharing the files, it would aggressively cache the data on the destination system.

The article is also a useful working example of how Process Monitor can help you to see what your machine is really up to. On the same subject, Mark gave a great Tech Ed presentation in Barcelona with some real-world demonstrations of how to use a variety of Sysinternals tools and utilities to detect, find and fix all sorts of system issues. A video of that talk entitled “The Case of the Unexplained…Live!” can be viewed here (it’s just over an hour long).

Download the Group Policy Settings Reference for Server 2008 in Excel 2007 (.xlsx) or older version (.xls) format.

Interestingly, this also includes 9 settings which are only available for Windows Vista service pack 1 (which also RTM’d last week). All of these are to do with controlling security settings for terminal services (RDP) sessions, including a setting I will find particularly useful to control whether a session can be established when the server cannot be authenticated.

This policy setting allows you to specify whether the client will establish a connection to the terminal server when the client cannot authenticate the terminal server. If you enable this policy setting, you must specify one of the following settings:

Always connect, even if authentication fails: The client connects to the terminal server even if the client cannot authenticate the terminal server.

Warn me if authentication fails: The client attempts to authenticate the terminal server. If the terminal server can be authenticated, the client establishes a connection to the terminal server. If the terminal server cannot be authenticated, the user is prompted to choose whether to connect to the terminal server without authenticating the terminal server.

Do not connect if authentication fails: The client establishes a connection to the terminal server only if the terminal server can be authenticated.

If you disable or do not configure this policy setting, the authentication setting that is specified in Remote Desktop Connection or in the .rdp file determines whether the client establishes a connection to the terminal server when the client cannot authenticate the terminal server.

This latest reference describes in detail 2,746 group policy settings, including the full explain text, which ones need a reboot, and to which operating systems they can be applied. This is up from the 2,494 which were available when Vista released to manufacture.

There is also one additional security setting for Vista SP1 and Server 2008 which will “Allow UIAccess applications to prompt for elevation without using the secure desktop”. This is intended for use when (for example) an administrator is providing Remote Assistance and may need to be able to provide credentials for a UAC prompt through their interactive desktop, whereas normally this prompt only appears on the secure desktop and is unavailable to anyone except someone at the keyboard in front of the machine. There are other settings relating to this which help to define which applications can be considered to have UIAccess which were already available in prior versions.

Read more about the release of Service Pack 1 for Vista here. The short version is that it won’t be available to actually download until mid-March

One of the benefits likely to get most press will be the changes to how Microsoft enforce their licencing through the “Windows Genuine Advantage” (WGA) programme which requires the software to be activated in order to continue using the full functionality. This has been held back from all the beta versions and will only take effect in the final released version. Paul Thurrott discusses this at his SuperSite for Windows:

First, Microsoft is disabling the two most common exploits that exist today for bypassing product activation in Vista … Pirate Windows users utilizing one of these hacks will see their systems return to the intended state–typically a grace period countdown–once SP1 is installed.

The second change is more dramatic. … If the product activation period expires, for example, Vista moves into Reduced Functionality Mode (RFM), where the user can only access the IE Web browser for 60 minutes at a time before being logged out; … Non-Genuine State (NGS), occurs when an activated copy of Vista fails a Web-based validation check, such as when you attempt to download software from the Microsoft Web site. In this case, certain features–like Windows Aero and ReadyBoost–are completely disabled, while others–like Windows Update and Windows Defender–work in limited ways only.

Beginning with SP1, RFM and NGS are a thing of the past.

Improvements to the software itself generally focus on performance and stability, but it does also improve on driver support and providing better APIs for third-party products such as anti-virus and desktop search (partly due to complaints that vendors were being “locked out” and could not develop products on an equal footing with Microsoft themselves).

One area which should be much better is the slow copying of files (even within a disk) which has plagued some systems. I will run some test copies of sets of large and small files and once I have the service pack installed I’ll post some results on how much performance gain I get.

There were various articles announcing Vista sp1, including one on the official Vista team blog which managed to say lots about all the good stuff and conveniently forget some things like the removal of the very useful GPMC, which is only mentioned in the whitepaper (and later reported on by various bloggers and journalists of varying degrees of credibility).

I have to admit that reading whitepapers can sound pretty dull, particularly when they relate to something I can’t download yet. I tend to think “I’ll read it nearer the time, once I have actually downloaded <whatever> and can apply what I am reading”. On this basis it is easy for people to overlook this announcement amid the other marketing hype.

In my mind there are two key questions here:
Firstly, I know there is supposed to be a new enhanced version of GPMC available at some point, but will it be available in time for the Beta testers? Or even for the final release of sp1? This remains unanswered at the moment, and is crucial. If it is available, it lessens the impact considerably.

Secondly, why take a retrograde step to remove something which is already in there? This second question is the one which most other commentators have addressed.

Jeremy Moskowitz, MVP for Group Policy makes some valid points on a post entitled “Vista + SP1 = Gbye GPMC” in his blog (sorry but I can’t find a way to link to the specific post):

Today, the GPMC is part of Vista. That’s great. One less thing to load.
But what’s also (now) true is that if you install SP1 for Vista (not yet available) the GPMC will be uninstalled. Why?

Because this allows for something that I’ve personally advocated for. That is, when new goodies are ready to be launched in Group Policy land, let’s GET IT OUT THE DOOR. And it used to be this way. The GPMC was a simple download and simple install. When bugs were found in the GPMC, that meant it was a quick fix to jam the fixes in, and re-upload the file for the masses.

But now (today) the GPMC is part of the Longhorn and Vista operating systems. Is this good? Not really, in this one dude’s opinion. Because what if some new whiz bang feature is suddenly available? Then you’ll have to wait until MAYBE an operating system service pack, or at worst a full operating system revision until it’s updated.

Darren Mar-Elia (another GP MVP) wrote a very extensive post about the Vista sp1 release, specifically pointing out lots of errors in one of the many articles about sp1. In it he takes up the same idea as Jeremy:

Back when GPMC first shipped, out-of-band of the OS, I’m sure Microsoft heard complaints that it should be in the OS, since it became such a crucial part of managing GP for many shops. So, they went and did the most logical thing – they put it in the box in Vista.

But to do that resulted in GPMC having to become part of the behemoth that is the Operating System release cycle at MS. This has obvious limitations if you know how glacially things move within MS when it comes to OS revs. Once inside the OS, they could no longer rev the GPMC and make enhancements to it on their own schedule.

However, I can’t see that the GPMC is so tightly integrated to the operating system as to prevent an update independently of the service pack cycle. The GP processing engine, sure (although making that its own process in Vista outside of winlogon should help with any patches that are needed). But the GPMC is an application. It does nothing until invoked by the user. I realise that it can still use shared code, but does it, in fact?

Anyway, if the GPMC so woven into the fabric of the OS that it can’t be independently tested and upgraded, how are they managing to take it out so easily? Surely that is contradictory?

Other OS components installed by default have upgrades made available periodically, the most obvious being Internet Explorer and Media Player. MS have claimed for a long time that both of these are fundamental components of the OS and it would not be possible to ship Windows without them unless it was severely crippled. This has been the basis of its defence in previous anti-competitive practices (antitrust) lawsuits. Microsoft just spent three years appealing a decision by the EU courts that ruled they had to produce a version of Windows XP without Media Player (which they have subsequently done for both XP and Vista)

Darren goes on to say:

But, with GPMC installed on every desktop, any joe user with normal non-administrative rights in the domain can open GPMC and view the settings on any GPO they have read access to! Further, they can also backup all GPOs that they have read permissions on, to, say, their USB keys

Technically true, and echoed by others. However, this overlooks the fact that to run GPMC on Vista in a default configuration the user requires local admin rights on their domain account (the local admin account won’t be able to access the domain policies, only the local ones). So yes, if you have domain users with local admin rights on their machines, they could run GPMC as described and take a copy of your policies. I’ll ignore for a moment the lack of security inherent with that model (because I accept there may be users who have a second account for doing admin things occasionally via a runas or UAC).
My question is this: surely a user sophisticated and malicious enough to do what Darren suggests would also be able to take the trivial step of installing GPMC if it was not already on their machine?

If they don’t have local admin rights they could still take a copy of the files for the policies they have read access to by going directly into the sysvol share. This would then take more effort to interpret than a GPMC report but they could easily restore them into another domain (in a virtual machine, say) in the same way you would have done before GPMC.

As a counter to this, surely we should be advising people to take more care in the creation of their Group Policies? It is very easy to ignore the security filtering for most purposes if you have designed your AD to enable you to target your policy links exactly where you need them. However, it may be prudent to remove “authenticated users” from the security filter (or via the delegation tab) and add back in only those groups who actually need to receive each policy.

You could start by having a security group for all computer accounts and another for users if you are following recommended practice of keeping the two types of settings separated and only enabling one ‘half’ of the policy. This would immediately secure your computer policies against the sort of access that we are concerned with here, including via sysvol. More granular groups would be ideal, but would increase the overhead of managing things.

So, I remain to be convinced that having GPMC pre-installed actually makes anything less secure than it already is. I am also unconvinced that it needs to be removed in order for independent updates to take place, as that would imply it was very tightly integrated in the OS, which would imply it could be quite hard to take out of the codebase, which seems to me a little contradictory.

I’ll just have to live without it, or install the enhanced version as long as it is available soon enough. It just still seems illogical.

Share this post :

I was pleasantly surprised to learn this, and it means I don’t have to wait for sp1.

OK, some of you must be thinking I have been hiding under a rock if I did not already know this, but I have found no mention in two books on Vista security (by Mark Minasi / Byron Hynes, and Jesper Johansson / Roger Grimes), nor another fat volume about Vista generally, nor a tome on Windows command line administration.

On the contrary, there are lots of misleading phrases that Bitlocker only encrypts the system volume (because they are trying to stress that it does not encrypt the boot volume, I guess), and even mention that if you use EFS for the additional volumes, and the EFS keys are on the system volume which is Bitlocker encrypted, then this is as good as Bitlocking the whole lot anyway. I can see the logic of that, but a little aside to say that you can use Bitlocker directly would have been helpful.

The Vista Resource Kit, however, does cover it, I now find (starting on page 527). A quick bit of Googling and the right page of the FAQ turned up this:

Will BitLocker encrypt more than just the operating system volume?

BitLocker provides a user interface for the encryption of the entire operating system volume, including Windows system files and the hibernation file. You can optionally use Encrypting File System (EFS) in Windows Vista to protect other volumes. The EFS keys are stored by default in the operating system volume. Therefore, if BitLocker is enabled for the operating system volume, all data that is protected by EFS is also indirectly protected by BitLocker. Additionally, advanced users can encrypt local data volumes using a command-line interface (manage-bde.wsf).

So, a bit of cscript manage-bde.wsf -? and we are on our way. But that’s for another day.

David Overton posted an article about what’s coming in the first service pack for Vista. In it he links to and quotes this BetaNews article which says:

the service pack will uninstall the Group Policy Management Console (GPMC) and GPEdit.msc will edit local Group Policy by default

So where did they get this important bit of information? It’s not in the Vista Team blog announcement, nor the extensive interview with Jon DeVaan, senior vice president of the Windows Core Operating System division at Microsoft.

It is in fact buried in the middle of the White Paper about the Vista sp1 Beta release, a document you may not have bothered to read in detail unless you are one of the lucky(?) 10,000 who will get to test this out. The relevant paragraph, in full, reads:

In addition to these changes, Windows Vista SP1 will change the tools that customers use to manage Group Policy. Administrators requested features in Group Policy that simplify policy management. To do this, the service pack will uninstall the Group Policy Management Console (GPMC) and GPEdit.msc will edit local Group Policy by default. In the SP1 timeframe, administrators can download an out-of-band release that will give them the ability to add comments to Group Policy Objects (GPOs) or individual settings and search for specific settings.

Now, I’m a bit of a zealot for good systems management (one of the original drivers for me writing this blog, and the idea for the name). I would also say I am an evangelist for Group Policy – particularly as one of the site admins for GPAnswers.com where there is a thriving community helping out people in difficulty over the intricacies of the subject.

I have heard lots of people say that adding GPMC into Vista “out of the box” was a good thing, and a few grumbling that there is no new version for XP/2003 yet, nor a downloadable version in case you break the built-in one (although that should be repairable in any case.

However, I have yet to hear of anyone saying they wish it was not there, and that it is too complex or gives too much power to someone. If you are one of these people, please let me know why you feel this way by leaving a comment. I hope to convince you of your error (told you I was an evangelist!)

The possible saving graces for me are these improved features which are discussed in the same white paper:

• BitLocker Drive Encryption encrypts extra local volumes. For example, instead of encrypting only drive C, customers can also encrypt drive D, E, and so on.
• Administrators can control the volumes on which to run Disk Defragmenter.

Both of these will be useful to me. I hope they make it through the Beta to the released version.

Spread the word :

As described in KB 911829 you may not be able to compose new or reply emails, create contacts or appointments, and other activities which are pretty essential. You can read your email, but you can do nothing else with them!

On a computer that is running Microsoft Windows Vista, you cannot perform any editing tasks that you typically expect to perform. For example, you cannot perform the following tasks:

• Compose a new e-mail message
• Reply to an e-mail message
• Create a new contact, task, note, journal entry, or appointment
• Change any configuration in the Outlook Web Access options folder

Additionally, you may receive an error message when you try to perform these tasks.

You could use the “basic” client to avoid the problem but this is only acceptable for occasional users. Road-warriors who come to rely on OWA as their main means of access to their corporate email and collaboration services need to get back the full rich “premium” experience.

So, before you roll out any Vista clients, get the Exchange server patched to avoid the issue.

Firstly, you need Exchange server 2003 service pack 2 to be installed, and then you can apply this hotfix