Windows 2003 x64 - GPMC cannot open Gpedit Snap-In
October 27th, 2005
I’ve get used to the GPMC (Group Policy Management Console) tool for managing group policies and delegate group policy privileges, by the way if you still use the Active Directory Users and Computers to administer Group Policy, I strongly encourage you to go to Microsoft’s Web site and download GPMC. (www.microsoft.com/windowsserver2003/gpmc/).
The only negative to using the GPMC is that you must install it and run it on a Windows XP or Windows Server 2003 computer, but believe me that it’s worth the effort.
Well, I’m not going to talk about the GPMC, there are many resources on the web to learn what is it about. This post reefers to an issue when you try to edit a group policy by right-clicking on a policy an select the Edit option on the GPMC, if you try this on a Windows 2003 x64 server you will get the following error:
—————————
gpedit.msc
—————————
Windows cannot find ‘gpedit.msc’. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search.
Digging through different newsgroups, I’ve found what is happening behind the scenes here.
This has to do with 32bit and 64-bit snap-ins, 32-bit and 64-bit MMC.exe, and 32-bit and 64-bit hosted snap-ins.
- MMC can be 32-bit or 64-bit. MMC.exe
- Snap-ins can be 32-bit or 64-bit. *.msc
- A snap-in can host other snap-ins (take computer management for example, it hosts a number of different snap-ins).
The explanation was taken from (http://support.microsoft.com/?id=304718)
Windows Server 2003 Administration Tools issues on x64-based versions of Windows Server 2003:
When you try to modify a GPO from the GPMC, a call is made to start the Gpedit.msc file. Currently, the snap-ins that call the Gpedit.msc file are 32-bit tools. However, on x64-based versions of Windows Server 2003, Gpedit.msc is a 64-bit snap-in.
This problem will be corrected in a future release of a 64-bit Adminpak.msi package.
To work around this problem, use either of the following methods.
Method one
Modify the GPOs from a computer that is running a 32-bit version of Windows Server 2003, a 32-bit version of Windows XP, or a version of Windows 2000.
Method two
Use the following commands to start the snap-ins, and then modify the GPOs:
- To start the Active Directory Users and Computers snap-in:
%windir%\syswow64\mmc.exe %windir%\system32\dsa.msc -32
- To start the Active Directory Sites and Service snap-in:
%windir%\syswow64\mmc.exe %windir%\system32\dssite.msc -32
- To start the Group Policy Management Console snap-in:
%windir%\syswow64\mmc.exe %windir%\system32\gpmc.msc -32
Running Windows 2003 Server Enterprise x64
October 25th, 2005
I’ve been running Windows 2003 Server Enterprise x64 for a while now, on a lab environment, in order to get familiar with common issues
before we deploy it as a production server. This post is aimed to share
the gained knowledge on this experience.
My experiences lies on an Intel EM64T architecture, with 1GB Memory and 3.0 Ghz CPU. When planning to deploy a Windows 2003 Server x64 OS first take a look at the hardware requirements:
A key feature of the 64-bit extended architecture is the capability to
run both 32-bit and 64-bit applications. The architecture defines
"Operating Modes" wich allows x64 enabled OS to run existing 32-bit
applications natively on a 64-bit processor without recompilation. The
capability to run 32-bit applications natively on the 64-bit processor
is a distinguishing feature of x64, and is possible because the x64
instruction set is an extension of the industry-standard x86
architecture. At first glance this sound great, you shouldn’t have any
problem using your actual 32bit applications on this new server,
but there are some things to be aware.
First, drivers, Windows Server 2003 x64 Editions
require all drivers (including all device drivers) to be 64-bit
drivers. All 32-bit kernel-mode drivers must be ported to 64-bit. So,
every specific vendor must provide a 64-bit driver for each device that
Windows Server 2003 does not provide it’s driver. In my case I
could’n get any driver for a network printer (HP Laserjet).
Second, virtual server, Virtual Server 2005 requires a 32-bit host operating system. Virtual
Server 2005 will run on x64-based hardware provided it is running a
32-bit version of a supported host operating system. Virtual Server
2005 R2 runs on both 32-bit and 64-bit (x64) host operating systems.
Virtual Server 2005 R2 supports AMD64 and Intel IA-32e/EM64T (x64)
processors. Note that Virtual Server 2005 R2 does not support Itanium
(IA-64) processors.
At the time of this writing, Virtual Server
2005 R2, is on Beta stage, so you can get it for free, for trial and testing purposes if you sign in, on the Microsoft Beta Place.
I had no problem using the Virtual Server 2005 R2, hosting many servers as we do on a production environment.
My advice, if you have bought an Intel EM64T procesor and you are
wondering whether to give a chance to Windows 2003 Server x64, go
ahead, just be aware of what we talked on this post and nothing
unexpected should happen to you.
On the other hand plan carefully and investigate the compability
between each Microsoft Server Solution (MS Exchange, ISA Server, WSS,
etc) that you want to deploy on the x64 platform. For instance, there
is a known issue between Windows 2003 Server x64 and WSS.
Related Links:
http://www.dell.com/downloads/global/power/ps2q05-20050116-Purush.pdf (Dell’s Deployment Guide)
http://www.dell.com/downloads/global/power/ps2q05-20050148-Purush.pdf (Dell’s Platform Overview)