Sam.McGeown.co.uk

If you read the Microsoft blurb for R2, the first thing you notice is that Server 2008 R2 is 64-bit only(!). It seems Microsoft are forcibly removing 32-bit server hardware from the data centre. I’ve not seen a decent upgrade guide online so far, so here’s my process.

I’m going to be upgrading a Server 2008 R2 x64 SP2 Standard Edition virtual server to R2. To see what editions can and can’t be upgraded, check out this Technet Article, but it’s safe to say that you can’t upgrade across architectures (32-bit to 64-bit) and you can’t downgrade SKUs (Enterprise to Standard).

The first step, as ever, is always to back up your server, if the upgrade goes wrong, you can always restore and try again. You have been warned!

So, without further ado, slip in your R2 DVD and begin…

Install

Update

Select your target SKU

Select “upgrade” (obviously :)

Check your upgrade report (which is saved as HTML on your desktop. The first time I ran this it said that I didn’t have enough free space – it required a whopping 15GB, which makes me think that this is no Server 2003 –> R2 upgrade, it’s the full blown OS install. Assuming everything checks out, go ahead.

Sit back and grab a cup of coffee. After a while, you’ll reboot

  and the upgrade begins in earnest. Once the process is completed, and another reboot has happened, you’ll be upgraded to R2. You’ll need to activate it with your R2 key.

Once you’re activated, update your server using Microsoft update or your patching method.

Et voila!

Windows Server 2008 Windows Server 2008, R2, Windows Server, Server, 2008, upgrade

I recently had an issue where a hosting environment was registering a lot of Netlogon Event 1030/1058 issues, being unable to find the Group Policy objects or download them. In this example, the server DC is the domain controller for DOMAIN.LCL.

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
Date:  10/09/2009
Time:  06:24:29
User:  NT AUTHORITY\SYSTEM
Computer: DC
Description:
Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1058
Date:  10/09/2009
Time:  06:24:29
User:  NT AUTHORITY\SYSTEM
Computer: DC
Description:
Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=DOMAIN,DC=LCL. The file must be present at the location <\\DOMAIN.LCL\sysvol\DOMAIN.LCL\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>. (Windows cannot find the network path. Verify that the network path is correct and the destination computer is not busy or turned off. If Windows still cannot find the network path, contact your network administrator. ). Group Policy processing aborted. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

On the affected machines, when navigating to \\DOMAIN.LCL there were no shares available, however navigating to \\DC shows the NETLOGON and SYSVOL shares. Pinging DOMAIN.LCL and then the DC showed that the IP addresses were not the same as expected, DOMAIN.LCL was resolving to the backup network, whereas DC was resolving to the servers LAN IP.

I checked the DNS records for the server, which were correct. Investigating the adaptor binding settings under Control Panel > Network Connections > Advanced > Advanced Settings showed that the backup network's adaptor was first in the list. I moved the adaptor for the LAN to the top of the list and OK'd my way out. I restarted the NETLOGON service and the issue was solved.

Windows servers have never been particularly good at being multi-homed, especially domain controllers. My advice comes from some bitter experience...

• If you have multiple network adaptors for extra bandwidth/redundancy/resiliance, then I would strongly recommend using Teamed adaptors, most of the major manufacturers' drivers and management software support it. This will eliminate any issues with multi-homing because as far as the server is concerned, it has one adaptor.
• If you have multiple network adaptors for different network segments and you're using RRAS to route between them, I would strongly suggest not using a Domain Controller at all for this purpose. Better yet, buy a hardware router.
• If you have multiple network adaptors for different purpose networks (e.g. a LAN, a backup network and an iSCSI network) then make sure you do the following:
  • Disable "File and Printer Sharing for Microsoft Networks" and "Client for Microsoft Networks" on all but the LAN adaptor.
  • Ensure that your LAN adaptor is the FIRST adaptor in the bindings in the advanced network settings.

 Hope that helps!

Active Directory, Networking, Windows Server 2000, Windows Server 2003, Windows Server 2008 multi-homed, domain controller, 2003, server 2003, server, network

We have a folder redirection policy in place for all of our users in combination with a roaming profile policy - this policy is applied to the OU that contains our users. Unfortunately this policy was accidently linked to the root of our domain too, causing our Domain Admin users to be redirected too - something we do not want. When the mistake was discovered, the policy was unlinked, but the redirection remained (despite being set to revert when users fall out of scope). I tried re-applying the policy, modifying the out of scope policy and then moving the Domain Admin user out of scope, but it failed to remove the folder redirection.

In the end, the solution was straight forward enough:

Create a new OU (I used "Temp") and move the affected user(s) there:

Create and link a new Group Policy Object to the new OU. Name it something descriptive so you know what it is in future - Folder Redirection Removal.

Edit the group policy, drill down to User Configuration > Windows Settings > Folder Redirection and right click - properties on each folder you want to reset. Set the setting to “Basic – Redirect everyone’s folder to the same location” and set the target folder location to “Redirect to the local userprofile location”.

Select the settings tab and make sure the Policy Removal setting is set to “Redirect the folder back to the local userprofile location when the policy is removed.”

Set that for each folder you want to reset. Close the Group Policy Object Editor, and GPMC. Log onto the user's account on each computer you want to remove the redirection on - in my case, several servers. Check the location of the redirected folders to make sure it’s been removed. Once you’re sure, you can move your user back to the correct OU.

Active Directory, User Profiles, Windows Server 2003, Windows Vista, Windows XP active directory, folder redirection, remove, user, accounts, server, 2003, group policy

Having just rebooted my laptop, I clicked on the link to open VMWare Infrastructure Web Access in the my browser and was slightly puzzled by the "page cannot be displayed" error. I figured it was probably the VMWare Server Web Access service not starting for some reason, so I opened services.msc and checked it out. The Web Access service was actually running, but the Host Agent service was not, so I tried to start it - it failed. Dutifully opening Event Viewer for some more information I found the error:

The VMware Host Agent service terminated with service-specific error 4294967295 (0xFFFFFFFF).

Great. Thanks for the elaboration. Time to check the VMWare logs, (c:\ProgramData\VMWare\VMWare Server\) - the most recent of which contained the following entry:

[2009-02-18 10:55:27.908 'App' 4408 info] Trying hostsvc
[2009-02-18 10:55:27.948 'App' 4408 panic] error: not well-formed (invalid token)
[2009-02-18 10:55:27.948 'App' 4408 panic] backtrace:(backtraces not supported)
[2009-02-18 10:55:27.948 'App' 4408 info] Win32 service stopped

 A bit of Googling pointed me in the right direction, "not well-formed" refers to the XML config files which are stored in c:\ProgramData\VMWare\VMWare Server\hostd, after that it was just a case of opening each one in turn until I found the malformed one. I backed it up and replaced it with a default version, and lo and behold, my services started!

VMWare vmware, server, web access, xml, not well-formed

32-bit processors have a limitation of only being able to directly address 4GB RAM - their architecture was never designed to address more. 64-bit processors get around that limitation by being able to us 64 bits to address RAM (potentially 16,777,216 GB), but what do you do if you have an application that won't work on a 64-bit copy of Windows, but does need to utilise more than 4GB of RAM?

The answer is to use PAE (Physical Address Extensions) and AWE (Application Windowing Extensions). I blundered through PAE a little while back, and found that it didn't work as expected because I was using Server 2003 Standard. PAE is only available as part of Server 2003 Enterprise and Datacenter edition.

Back to the problem at hand, I have a memory hungry application that sits on a Windows Server 2003 Enterprise box with SQL server 2005 installed.

Firstly, we need to enable PAE to allow the 32-bit operating system to address memory over the 4GB limit. This is configured by adding the /PAE switch to the boot.ini.

We also need to repartition the 4GB of Virtual Address Space (VAS) that 32-bit Windows can address by using the /3GB switch in the boot.ini. This allows 3GB of RAM to processes running in "Application Mode" and 1GB RAM to the "Kernel Mode". If you're using more the 16GB of memory don't use the /3GB switch as PAE/AWE will need 2GB of RAM in the Kernel Mode.

The memory intensive applications will run in, you guessed it, Application Mode and will therefore be able to utilise the extended memory provided through PAE and AWE.

Since SQL server will run in the Application Mode memory partition and is AWE aware, it can be configure to reside entirely in AWE managed memory.

The user account that is used to run SQL server must be granted the "Lock Pages in Memory" right and the "AWE Enabled" setting in the configuration of SQL server must be set to "1". We also need to set the "Max Server Memory" to stop SQL server consuming all the AWE memory available. The "Min Server Memory" does not need to be configured as AWE memory is not released by SQL server.

Once that is all configured and a reboot applied, SQL server should only consume about 256mb in task manager, the rest having been loaded into AWE memory and not viewable from the Task manager.

Windows Server 2003, SQL Server 2005 pae, awe, sql, server, windows, windows server 2003, sql server 2005