[gview file=”http://www.techpository.com/wp-content/uploads/2011/09/iSCSI-Initiator-Users-Guide-for-Windows-7.doc”]

When you launch Windows Event Viewer, one of the following error messages may occur if one of the *.evt files is corrupt:

The handle is invalid

Dr. Watson Services.exe
Exception: Access Violation (0xc0000005), Address: 0x76e073d4

When you click OK or cancel on the Dr. Watson error message, you may also receive the following error message:

Event Viewer
Remote Procedure Call failed

The services.exe process may consume a high percentage of CPU utilization.

Back to the top

CAUSE

The Event Viewer Log files (Sysevent.evt, Appevent.evt, Secevent.evt) are always in use by the system, preventing the files from being deleted or renamed. The EventLog service cannot be stopped because it is required by other services, thus the files are always open. This article describes a method to rename or move these files for troubleshooting purposes.

Back to the top

RESOLUTION

ImportantThis section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

Back to the top

NTFS Partition

1. Click the Start button, point to Settings, click Control Panel, and then double-click Services.
2. Select the EventLog service and click Startup. Change the Startup Type to Disabled, and then click OK. If you are unable to log on to the computer but can access the registry remotely, you can change the Startup value in the following registry key to 0x4:
   HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlog
3. Restart Windows.NOTE: When the system starts up, several services may fail; a message informing the user to use Event Viewer to review errors may appear.
4. Rename or move the corrupt *.evt file from the following location:
   %SystemRoot%System32Config
5. In Control Panel Services tool, re-enable the EventLog service by setting it back to the default of Automatic startup, or change the registry Startup value back to 0x2.

Back to the top

FAT partition (Alternative method)

1. Boot to a MS-DOS prompt using a DOS bootable disk.
2. Rename or move the corrupt *.evt file from the following location:
   %SystemRoot%System32Config
3. Remove the disk and restart Windows.

When Windows is restarted, the Event Log file will be recreated.

While Active Directory in general uses a multimaster replication scheme for replicating the directory database between domain controllers, there are certain directory functions that require they be performed on some specific domain controller. These functions are defined by flexible single master operations (FSMO) roles (pronounced “fiz-moe roles”) and at any time these roles are uniquely assigned to specific domain controllers in different Active Directory domains. Let’s begin by describing what these different FSMO roles are and why they are important, after which we’ll outline some best practices for how you should assign these roles in your Active Directory environment.

Overview of FSMO Roles

There are five different FSMO roles and they each play a different function in making Active Directory work:

• PDC Emulator – This role is the most heavily used of all FSMO roles and has the widest range of functions. The domain controller that holds the PDC Emulator role is crucial in a mixed environment where Windows NT 4.0 BDCs are still present. This is because the PDC Emulator role emulates the functions of a Windows NT 4.0 PDC. But even if you’ve migrated all your Windows NT 4.0 domain controllers to Windows 2000 or Windows Server 2003, the domain controller that holds the PDC Emulator role still has a lot to do. For example, the PDC Emulator is the root time server for synchronizing the clocks of all Windows computers in your forest. It’s critically important that computer clocks are synchronized across your forest because if they’re out by too much then Kerberos authentication can fail and users won’t be able to log on to the network. Another function of the PDC Emulator is that it is the domain controller to which all changes to Group Policy are initially made. For example, if you create a new Group Policy Object (GPO) then this is first created in the directory database and within the SYSVOL share on the PDC Emulator, and from there the GPO is replicated to all other domain controllers in the domain. Finally, all password changes and account lockout issues are handled by the PDC Emulator to ensure that password changes are replicated properly and account lockout policy is effective. So even though the PDC Emulator emulates an NT PDC (which is why this role is called PDC Emulator), it also does a whole lot of other stuff. In fact, the PDC Emulator role is the most heavily utilized FSMO role so you should make sure that the domain controller that holds this role has sufficiently beefy hardware to handle the load. Similarly, if the PDC Emulator role fails then it can potentially cause the most problems, so the hardware it runs on should be fault tolerant and reliable. Finally, every domain has its own PDC Emulator role, so if you have N domains in your forest then you will have N domain controllers with the PDC Emulator role as well.
• RID Master – This is another domain-specific FSMO role, that is, every domain in your forest has exactly one domain controller holding the RID Master role. The purpose of this role is to replenish the pool of unused relative IDs (RIDs) for the domain and prevent this pool from becoming exhausted. RIDs are used up whenever you create a new security principle (user or computer account) because the SID for the new security principle is constructed by combining the domain SID with a unique RID taken from the pool. So if you run out of RIDS, you won’t be able to create any new user or computer accounts, and to prevent this from happening the RID Master monitors the RID pool and generates new RIDs to replenish it when it falls beneath a certain level.
• Infrastructure Master – This is another domain-specific role and its purpose is to ensure that cross-domain object references are correctly handled. For example, if you add a user from one domain to a security group from a different domain, the Infrastructure Master makes sure this is done properly. As you can guess however, if your Active Directory deployment has only a single domain, then the Infrastructure Master role does no work at all, and even in a multi-domain environment it is rarely used except when complex user administration tasks are performed, so the machine holding this role doesn’t need to have much horsepower at all.
• Schema Master – While the first three FSMO roles described above are domain-specific, the Schema Master role and the one following are forest-specific and are found only in the forest root domain (the first domain you create when you create a new forest). This means there is one and only one Schema Master in a forest, and the purpose of this role is to replicate schema changes to all other domain controllers in the forest. Since the schema of Active Directory is rarely changed however, the Schema Master role will rarely do any work. Typical scenarios where this role is used would be when you deploy Exchange Server onto your network, or when you upgrade domain controllers from Windows 2000 to Windows Server 2003, as these situations both involve making changes to the Active Directory schema.
• Domain Naming Master – The other forest-specific FSMO role is the Domain Naming Master, and this role resides too in the forest root domain. The Domain Naming Master role processes all changes to the namespace, for example adding the child domain vancouver.mycompany.com to the forest root domain mycompany.com requires that this role be available, so you can’t add a new child domain or new domain tree, check to make sure this role is running properly.

To summarize then, the Schema Master and Domain Naming Master roles are found only in the forest root domain, while the remaining roles are found in each domain of your forest. Now let’s look at best practices for assigning these roles to different domain controllers in your forest or domain.

FSMO Roles Best Practices

adve

Proper placement of FSMO Roles boils down to three simple rules:

• Rule One: In your forest root domain, keep your Schema Master and Domain Naming Master on the same domain controller to simplify administration of these roles, and make sure this domain controller contains a copy of the Global Catalog. This is not a hard-and-fast rule as you can move these roles to different domain controllers if you prefer, but there’s no real gain in doing so and it only complicates FSMO role management to do so. If for reasons of security policy however your company decides that the Schema Master role must be fully segregated from all other roles, then go ahead and move the Domain Naming Master to a different domain controller that hosts the Global Catalog. Note though that if you’ve raised your forest functional level to Windows Server 2003, your Domain Naming Master role can be on a domain controller that doesn’t have the Global Catalog, but in this case be sure at least to make sure this domain controller is a direct replication partner with the Schema Master machine.
• Rule Two: In each domain, place the PDC Emulator and RID Master roles on the same domain controller and make sure the hardware for this machine can handle the load of these roles and any other duties it has to perform. This domain controller doesn’t have to have the Global Catalog on it, and in general it’s best to move these two roles to a machine that doesn’t host the Global Catalog because this will help balance the load (the Global Catalog is usually heavily used).
• Rule Three: In each domain, make sure that the Infrastructure Master role is not held by a domain controller that also hosts the Global Catalog, but do make sure that the Infrastructure Master is a direct replication partner of a domain controller hosting the Global Catalog that resides in the same site as the Infrastructure Master. Note however that this rule does have some exceptions, namely that the Infrastructure Master role can be held by a domain controller hosting the Global Catalog in two circumstances: when there is only one domain in your forest or when every single domain controller in the domain also hosts the Global Catalog.

To summarize these three rules then and make them easy to remember:

• Forest root domain – Schema Master and Domain Naming Master on the same machine, which should also host the Global Catalog.
• Every domain – PDC Emulator and RID Master on the same machine, which should have beefy hardware to handle the load.
• Every domain – Never place the Infrastructure Master on a machine that hosts the Global Catalog, unless your forest has only one domain or unless every domain controller in your forest hosts the Global Catalog.

When a RDP session is blacked out at the login screen, if you goto (HKEY_USERS.DEFAULTControl PanelColors) on that server in the registry you will probably see all of the configurations = 0. This can be fixed by replacing the 0’s with the correct parameters.
Enter the following parameters:

HKEY_USERS.DEFAULTControl PanelColors
"ActiveBorder"="212 208 200"
"ActiveTitle"="0 84 227"
"AppWorkSpace"="128 128 128"
"Background"="0 78 152"
"ButtonAlternateFace"="181 181 181"
"ButtonDkShadow"="113 111 100"
"ButtonFace"="236 233 216"
"ButtonHilight"="255 255 255"
"ButtonLight"="241 239 226"
"ButtonShadow"="172 168 153"
"ButtonText"="0 0 0"
"GradientActiveTitle"="61 149 255"
"GradientInactiveTitle"="157 185 235"
"GrayText"="172 168 153"
"Hilight"="49 106 197"
"HilightText"="255 255 255"
"HotTrackingColor"="0 0 128"
"InactiveBorder"="212 208 200"
"InactiveTitle"="122 150 223"
"InactiveTitleText"="216 228 248"
"InfoText"="0 0 0"
"InfoWindow"="255 255 225"
"Menu"="255 255 255"
"MenuBar"="236 233 216"
"MenuHilight"="49 106 197"
"MenuText"="0 0 0"
"Scrollbar"="212 208 200"
"TitleText"="255 255 255"
"Window"="255 255 255"
"WindowFrame"="0 0 0"
"WindowText"="0 0 0"