Exchange Server 2007SP1 and IPv6 Issues

Our Exchange Server has been in production now for a week and there are some significant issues coming up that relate to speed. It appears that running IPv6 on this server creates a major speed issue. This could be seen in very slow client access (oftentimes you will see a message like “Trying to connect to Microsoft Exchange” and a user may even be prompted for their username and password) and the Exchange Management Console and Shell are also performing very poorly with waits up to several minutes to access information or initialise. However it is not as simple as turning off IPv6 on the network adapter as the result can be that the ExchangeTransport service will hang and crash. That was our experience this week. Our consultant had turned off IPv6 in the network adapter’s properties, but the next time the server was restarted, ExchangeTransport Service would not start and would usually crash every 5 minutes. This service is key to the Hub Transport role and your Exchange server will not be able to deliver any mail if it is not operating. Rechecking IPv6 on the adapter caused the problems of ExchangeTransport service to go away but the performance issues immediately returned.

Our next step to try (tomorrow probably) is to disable IPv6 outright as described in this MSKB article. Additional relevant information can be found here, here, here, here, here and here. This MSKB article is also very important because it details situations where the KB952842 article may be incorrect due to the roles in use on the server. It will be noticed that most of the articles referenced above are not concerned with performance, but with the ExchangeTransport service failure. I have not yet found very much about performance issues, but it seems highly likely this is the cause of our problems at the present time.

Rolling out Vista to Student Desktops - 3

Last time I looked at this was some 9 months ago. It will become more important as time goes on, but it hasn’t been a priority much lately. The main difference is that with a Hyper-V server I now have some Vista VMs to use as test configurations. If we ever went to a lab of Vista machines there would be a lot of work needed on things like a Key Management Server for activations, for example.

The latest oddity to surface from Vista on some user accounts recently is being unable to browse the Internet unless your account is a local administrator of the machine. I noticed this working on a Vista laptop in our site today and have confirmed it is not confined to that machine. Since the virtual machines have a fairly minimal configuration, we can rule out a lot of things from the extra software that laptop makers typically provide these days (such as security managers or TPM type stuff). At the moment that doesn’t really get me any further except that I have confirmed it is not happening on XP machines so it seems just to be a function of Vista to date.

Just for a comparison I started up one of my Windows 7 virtual machines to see how it would handle a mandatory profile login. There were no issues that I could see. Both the Windows 7 machine and the Vista machine were able to redirect the Documents folder correctly. Both have the same problem in the web browser with what appears to be obsolete proxy configuration settings, meaning that I have to test out what the settings actually are for some of our computers and where they have actually been set up. I have not at this stage attempted further testing of Start Menu redirection which we have used in the past, and I still have to deal with Vista’s dual Document folders (we would want to remove the local folder).

OMNIS (RM Integris) on Windows Vista may be incompatible with Microsoft Groove

Refer to my previous article about setting appcompat settings for Omnis.exe to Windows 2000 in order to eliminate calls to EncodePointer and DecodePointer (functionality added to Windows XP Service Pack 2).

On a new Windows Vista system, RM Integris (Omnis.exe) crashed upon first execution when it reached the “Open / Create Datafile” dialog. The application was traced with Microsoft Dependency Walker and it recorded an Access Violation in GrooveUtil.DLL, a component of Microsoft Groove (itself a part of Microsoft Office Enterprise 2007) (Error 0xC0000005). This occurred without any user notification (the application unexpectedly quit without displaying any error dialog, and no event was logged by Windows). Uninstalling MS Groove from Office 2007 has cured the problem to date.

Automating Windows Vista Installations - 4

After capturing our new Vista image using Ghost and ImageX, the reference PC was rebooted to effectively apply it. A second PC of identical hardware configuration had the image applied to it using Ghost. First time startup with the image takes around 20 minutes to complete before the normal Windows logon comes up.

Issues found for this specific installation:

• Still asked for a user account and password to be created. In future we may specify a dummy account and a very long gibberish password so the account doesn’t have to be deleted later.
• Still asked for a network location to be specified
• Display drivers were not installed
• Domain was not joined (Error 0x5 was recorded in the Setup logs, this translates to “Access denied” which could mean a million things in this context)
• And of course, the Tablet PC input panel came up again.

In other words, the only change that has been applied is that the administrator account is enabled with its password set. As I had researched the other changes or checked the existing settings were correct, I don’t know what else I can do at this stage to rectify the above issues. They are minor points but it is quite annoying to have gone through this amount of work so far and done everything supposedly “by the book” yet have the issues unrectified. The display drivers, of course, might require Intel’s custom setup application to be run, and so may have to be automated a different way.

The Tablet PC input panel, of course, is not being affected by Sysprep. It is just a default setting for newly installed PCs and is a trivial matter to disable. This time around the Language Bar didn’t open so that is one less thing to do.

At this time I am still using Ghost but have decided to install WDS on one of our servers and then skill myself in the techniques. I like the PXE based solution because you can eliminate the manual step of having to start up Ghost before each installation and don’t need a working CD drive on the target machine. We also don’t have enough Ghost licenses at present. So if WDS works out I will be using it to deploy Vista and later, while still using Ghost with our legacy XP images.

Automating Windows Vista Installations - 3

Continuing the series on automation of Windows Vista installations, the first article covered the creation of our first Vista image. Prior to this time I had some experience of ImageX from using it to image a PC that was running Vista, however I had not used Sysprep with this PC and therefore the image was not suitable for cloning. When we updated Ghost to version 11, I became aware that it was Vista capable. At that time also I was mainly familiar with the use of Ghost without Sysprep, in which with Windows 98 machines in the main a SID regeneration process was not required. My next step when our network transitioned to XP was to learn the use of RIS with the consideration that we might eliminate the use of Ghost within our organisation. Due to the limitations of RIS (such as not being able to copy junction points, meaning incompatibility with Microsoft .NET Framework) I moved back to the use of Ghost and learned in relatively recent times how to use Sysprep with its answer file to prepare an image for cloning on our network. Thus it is only in the last two years that we have made use of Ghost with Sysprep for imaging Windows XP machines. Rather than learn WDS I will be continuing the use of Ghost, but also hedging my bets by creating a WIM version of each Vista image as well, in the event we might decide to use ImageX or WDS in the future instead of continuing with Ghost.

The second article covered the lessons learned in our first production deployment of an image to a laptop, and the issues created. Subsequently the same image was deployed to a different hardware platform as a first step to creating a specific image for that platform.  This third article will cover changes made to our configuration and answer file as well as the imaging and production deployment experience. As before, I am making use of a Hyper-V virtual machine to test the WIM version of the image. The first issue I am addressing is the non enablement of the administrator account. I identified that I had entered the NET USE command instead of NET USER, However, the WSIM documentation does not advocate the use of the NET USER command to enable; instead it suggests using Autologon settings. I addressed the issue of non joining the domain by using the account specified in the answer file to join this reference machine to the domain, so that hopefully the account should be recognised this time. One thing that did work out was the locale settings, which turned out to be more or less correct, but I am changing them using this reference. The final issue that I would like to resolve this time around is the installation of the graphics driver. There are a lot of methods provided in Vista Setup tools to add the drivers. The easiest for me is to specify the drivers path in the answer file, since I am already familiar with this use of WSIM. The best place, of course, to have these drivers is in a file on the laptop’s HDD that is deployed with the image. This is why HP laptops have the SWSETUP directory; a variation of this is very commonly seen in mass deployed PCs such as OEM built systems. One thing I learned with RIS, waaaay back, was how to deploy Intel NIC drivers at the early stages of RIS text based setup when the target PC had to connect to the network for the very first time to get Setup started. That is a boot level driver deployment and may be required for WDS type scenarios, or using Windows PE. We don’t need it here because of using Ghost instead. In this scenario the graphics drivers are to be deployed in the OfflineServicing pass.

Having completed our answer file, I copy a predefined command script to C:\Windows\System32\Sysprep and then copy my answer file and rename it to the filename specified in the script. I then run the script to sysprep the reference PC and automatically shut it down, before Ghosting and ImageX-ing it.  The results will be published in Article 4 of this series.

Automating Windows Vista Installations - 2

Following on from the comment in the first article, I created the xml file for Sysprep and used it to sysprep the image of the source machine. I then took two machine images, one using Ghost 11 and one using ImageX. I then loaded the Ghost image back to the original machine after formatting its C drive. The ImageX image was applied to a new Hyper-V virtual machine for further testing. Both of these computers were first booted using Windows PE. After rebooting into the respective OS images, Sysprep has done its usual thing, which is massively slower than on XP.

The documentation that is supplied with WSIM is quite comprehensive, yet at times it is too technical, for example when I set locale information I have no idea where to put in “en-nz” and where to put in “en-us” because the only “en” that I could find mentioned is “en-us”.

Issues with the process of the Sysprepped images:

• Windows forces you to create a local user account with a password and hint, even though we set up the administrator account to be enabled and gave it a password. This creates an unnecessary extra step of having to remove this account at first login.
• The administrator account is still disabled even though I specified that it be enabled.
• The computer hasn’t joined the domain even though I put in all the settings for it into the sysprep xml file. Instead it has joined a workgroup with the name specified.
• The network location setting that I specified with WSIM is not being applied.
• The graphics driver that was installed on the reference computer has not been reinstalled at first startup. It would be quite reasonable and convenient for Windows to cache the previously installed drivers for use when the machine is loaded; but it doesn’t do this. I suspect the lack of joining the domain is due to a lack of network card drivers, although it could also be a user account problem. This is all a complete pain because we now have to specify all the drivers to be loaded with each image so it just makes extra work when a particular image is set up for use with particular hardware.
• The Tablet Input Panel has come back when I banished it originally (the interactive whiteboard drivers are treated as a tablet device. This does have the advantage that you can use the interactive whiteboard to do some tabletty type things; but you don’t have the button controls on the interactive whiteboard that an actual tablet PC would have).

I expect most of these issues will eventually be solved satisfactorily. It is a new learning curve with a complete new set of tools. The main advantage of using Ghost is that the disk doesn’t have to be partitioned and formatted; with ImageX this is an additional step. However these are not great differences that would really make me choose Ghost over ImageX. Ghost is still the best system for deploying to multiple machines and over a network, whereas ImageX is the simple one to use with a USB hard disk or some other file based mechanism (although I mapped a network drive to install it off the network). Unless we decide to use WDS in the future, I don’t really know whether Ghost or ImageX will turn out to be the better solution for our needs.

Automating Windows Vista Installations

When you are a system administrator, pretty much an important thing is to work out how to streamline setup and installation of computers using various kinds of mass duplication techniques. Historically one of the best known systems for doing this has been Binary Brothers’ Ghost software, now known as Symantec Ghost Solution Suite. Microsoft has always provided support for third party software such as this, while progressively over time devising its own equivalents. In the era of Windows Server 2003/Windows XP, the equivalence was provided for the first time in a system called Remote Install Services. I learned how to use it alongside my existing Ghost experience, and eventually concluded that due to certain RIS limitations, we would continue with Ghost for the time being; I then learned how to sysprep Windows XP images with Ghost and began cloning them across various architectures and platforms.

With the introduction of the Vista/2008 platform, Microsoft has revisited the automation scene and created new tools; they reasoned, correctly, that new imaging system are not only useful to mass duplication scenarios, the techniques employed can also be applied to personal installations on single computers. Specifically, disk imaging techniques are used to perform Vista and Windows 7 installations onto computers when using setup DVDs. This has resulted in a much faster installation experience for the majority of users. Microsoft has also sought to enhance its network-based installation technology, RIS, into a new product called Windows Deployment Services.

Of course, as a sysadmin, I now have to learn the new systems that Microsoft has compelled implementation of through Windows Vista. The latest version of Ghost can image Vista, but in order to get to a useable image at the end of it, we still have to use Microsoft’s technologies to prepare the source computer, and along the way, I’ll be covering my bases by using Microsoft’s imaging software, ImageX, as well. To get things going, I found these articles:

Deploying Vista with SysPrep and Imagex – The basics and getting started

Windows Vista USB Automated Install – creating the unattended installation file for Sysprep

To get started I am creating the sysprep.xml file using the settings shown in the first article. One question is that we are currently using a MAK. I don’t know whether I will put the key into my Sysprep.xml file. I might leave it out so that Vista can try activating to a Key Management Server, because although we don’t have enough Vista computers to use a KMS right now, we will in the future.

Before you can get going with this stuff, you have to install the Windows Automated Installation Kit from Microsoft. There have been a couple of releases; since I have SP1 of Vista I am using the 6001 release. It comes as a download of an ISO file; you can extract the files using 7Zip. An annoyance I am finding with Windows SIM is that it won’t mount an image that is on a network share. So much of this happens in Vista, that installations won’t run from a network share, yet the error message is some other silly thing. It seems in many ways that Microsoft has created this newly restrictive environment in Vista, yet they haven’t integrated the restrictions in the operating system in a way that is transparent to users or produces meaningful error messages.