Alberto Ortega’s Blog

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

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)

After you installed your MOM Reporting server, the next thing you should do is to import all reports included in the MOM Management Packs.

During the MOM Reporting setup the Reporting User Account must be specified. If this account is not part of the BUILTIN\Administrators group on the Reportig Server, any attempt to render the reports will have the same error as output:

…( rsProcessingAborted )…
Logon failure: the user has not been granted the requested logon type at this computer.

This is because Default security settings on SQL Reporting Services list only the BUILTINT\Administrators group as the allowed users to execute reports. You have tow possible solutions:

1. Make the Reporting User Account member of a group that is member of the BUILTIN\Adminsitrators group on the MOM Reporting Server. (Not so desirable for the security environment)
2. Add a security group that the Reporting User Accounts belongs to, to the SQL Server Services security settings. (Recommended)

Solving this permissions issue you will be able to see any Management Pack report. Enjoy!

After you installed MOM Reporting Server the SQLAgent service began reporting the same recurrent error:

Event ID: 318
Unable to read local eventlog (reason: The data area passed to a system call is too small).

If you pay attention this error occurs everytime the MOM Reporting DTS package runs. Don´t worry about it, this is a known bug in DTS in SQL Server that occurs when a DTS package
logs to the event log and has more then 50 steps (KB: http://support.microsoft.com/?id=811484 ). The MOM Reporting DTS package fits this description. You can ignore the error as nothing has failed or gone wrong.

You might check the event log to make sure your DTS package is succeeding.

There is an issue when trying to install a MOM 2005 Database Server on a SQL Server 2000 wich has SP4 installed on it.

The required version is SQLServer 2000 + SP3a, installation should be possible since SP4 is a newer SP than SP3, to troubleshoot this, do the following:

Alter the CSDVersion entry located at:
HKEY_Local_Machine\SOFTWARE\Microsoft\Microsoft SQL Server\SQL2000\MSSQLServer\CurrentVersion

If SP4 is installed, the version number will be 8.00.2039. To get the MOM 2005 Database to install, you need to change the version number to 8.00.761 which is the same one for SP3A and then change it back again after the installation is completed.

This Issue will be solved by MOM 2005 SP1, for the meanwhile this workaround should work for you.

Besides that, the SQL Server and SQL Server Agent services must be in automatic startup mode, for clusters they can be manual startup.

After this configuration is performed you will be pass the pre-requisites step and you can install the MOM 2005 Databa Server.

t’s a very common issue to get this Application error on a Back-End Exchange Server 2003. One thing we know, it’s an LDAP error, but sometimes it can become very tricky to get rid of.
This error look like this on the Event Application Log:

LDAP returned the error [20] No Such Object when importing the transaction

dn: <GUID=546E8A04-4E64-4EE0-850C-1093237A65F7>

changetype: Modify

member:add:<GUID=A0005D87-5BDC-4000-8816-889B80C4A619>

-

DC=domain,DC=com

For more information, click http://www.microsoft.com/contentredirect.asp.

And generally you are likely to receive more than one of these errors logged.

First follow this easy work around that you can found in many places:

1) Move the following groups to the default User container, on every domain that you have run domainprep setup:
a. The Exchange Enterprise Servers group.
b. The Exchange Domain Servers group.
c. The Exchange Services group.

2) Check to make sure there is an Exchange Domain Servers group in each domain. If there isn’t then run setup /domainprep in each child domain.

If none of those helped you, let’s dig deeper into the error. If we analyze what is being logged, we can discover some interesting issues. What this LDAP command is trying to do is to modify an AD object add another AD object to it. That is:

LDAP returned the error [20] No Such Object when importing the transaction

dn: <GUID=546E8A04-4E64-4EE0-850C-1093237A65F7> (object being modified - container)

changetype: Modify (command: Modify)

member:add:<GUID=A0005D87-5BDC-4000-8816-889B80C4A619> (object being added to container )

-

DC=domain,DC=com

For more information, click http://www.microsoft.com/contentredirect.asp.

So, the MSExchangeAL service cannot perform this operation. To solve this issue we are going’ to manually perform the operation.

First, we have to know which AD Objects those GUID’s are refereeing to. To accomplish these task we use a tool called ADFind to translate the GUID’s to domain names that we can easily find on the forest.

Download the ADFind tool from http://www.joeware.net/win/free/tools/adfind.htm

Then execute the tool like this:

–Find the object being modified (container):

adfind -gc -b -binenc -f "(objectGuid={{GUID:546E8A04-4E64-4EE0-850C-1093237A65F7}})" –dn

If the object exists we will get the AD common name:

Ex: CN=Exchange Enterprise Servers,CN=Users,DC=domain1,DC=com

–Find the object being added to the container:

adfind -gc -b -binenc -f "(objectGuid={{GUID: A0005D87-5BDC-4000-8816-889B80C4A619}})" –dn

If the object exists we will get the AD common name:

Ex: CN=Exchange Domain Servers,CN=Users,DC=domain2,DC=ws

After that we realize that the task that the LDAP query wanted to do was to Add the Exchange Domain Servers security group from domain2 to the Exchange Enterprise Servers security group from domain1. Now go using AD Users an Computers Snap-in to do the task manually and the error will go away.

Related Links:

LDAP Errors : http://www.eventid.net/display.asp?eventid=8270&eventno=332&source=MSExchangeAL&phase=1