Archive for the ‘Server’ Category

The /32 and /64 parameters for the mmc command are meaningful only on 64-bit Windows versions. The 64-bit versions of the Windows operating system can run both 32-bit and 64-bit versions of the MMC. For 32-bit versions of the MMC, you use 32-bit snap-ins. For 64-bit versions of the MMC, you use 64-bit snap-ins. You can’t mix and match MMC and snap-in versions, though. The 32-bit version of the MMC can be used only to work with 32-bit snap-ins. Similarly, the 64-bit version of the MMC can be used only to work with 64-bit snap-ins. In most cases, if you aren’t sure which version to use, don’t use the /32 or /64 parameter. This lets the Windows operating system decide which version to use based on the snap-ins contained in the .msc file you are opening.

 

When a console contains both 32-bit and 64-bit snap-ins and you don’t specify the /32 or /64 parameter, Windows will open a subset of the configured snap-ins. If the console contains more 32-bit snap-ins, Windows will open the 32-bit snap-ins. If the console contains more 64-bit snap-ins, Windows will open the 64-bit snap-ins. If you explicitly use /32 or /64 with a console that contains both 32-bit and 64-bit snap-ins, Windows will open only the snap-ins for that bitness. On 64-bit systems, 32-bit versions of snap-ins are stored in the %SystemRoot%\SysVoL64 folder and 64-bit versions of snap-ins are stored in the %SystemRoot%\System32 folder. By examining the contents of these folders, you can determine when 32-bit and 64-bit versions of snap-ins are available.

1. To restore the system state on a domain controller, first start the computer in Directory Services Restore Mode. To do so, restart the computer and press the F8 key when you see the Boot menu.

2. Choose Directory Services Restore Mode.

3. Choose the Windows 2000 installation you are going to recover, and then press ENTER.

4. At the logon prompt, supply the Directory Services Restore mode credentials you supplied during the Dcpromo.exe process.

5. Click OK to acknowledge that you are using Safe mode.

6. Click Start, point to Programs, point to Accessories, point to System Tools, and then click Backup.

7. Click the Restore tab.

8. Click the appropriate backup media and the system state to restore.

NOTE: During the restore operation, the Winnt\Sysvol folder must also be selected to be restored to have a working sysvol after the recovery process. Be sure that the advanced option to restore “junction points and data” is also selected prior to the restore. This ensures that sysvol junction points are re-created.

9. In the Restore Files to box, click Original Location.

NOTE: When you choose to restore a file to an alternative location or to a single file, not all system state data is restored. These options are used mostly for boot files or registry keys.

10. Click Start Restore.

11. After the restore process is finished, restart the computer.

Intersite replication takes place between sites. Intersite replication can utilize either RPC over IP or SMTP to convey replication data. This type of replication has to be manually configured. Intersite replication occurs between two domain controllers that are called bridgeheads or bridgehead servers. The role of a bridgehead server (BS) is assigned to at least one domain controller in a site. A BS in one site deals with replicating changes with other BSs in different sites. You can configure multiple bridgehead servers in a site. It is only these BSs that replicate data with domain controllers in different domains by performing intersite replication with its BS partners. With intersite replication, packets are compressed to save bandwidth. This places additional CPU load on domain controllers assigned the BS role. BSs should therefore be machines that have enough speed and processors to perform replication. Intersite replication takes place over site links by a polling method which is every 180 minutes by default.

ADSIEdit is a Microsoft Management Console (MMC) snap-in that acts as a low-level editor for Active Directory. It is a Graphical User Interface (GUI) tool. Network administrators can use it for common administrative tasks such as adding, deleting, and moving objects with a directory service. The attributes for each object can be edited or deleted by using this tool. ADSIEdit uses the ADSI application programming interfaces (APIs) to access Active Directory. The following are the required files for using this tool:

ADSIEDIT.DLL

ADSIEDIT.MSC

Regarding system requirements, a connection to an Active Directory environment and Microsoft Management Console (MMC) is necessary.

The tombstone lifetime is determined by the value of the tombstone Lifetime attribute on the Directory Service object in the configuration directory partition.

Administrative Credentials

To complete this procedure, you must be a member of the Domain Users group.

 

To determine the tombstone lifetime for the forest

1.            On the Start menu, click Run, type adsiedit.msc, and then click OK.

2.            In the console tree, double-click Configuration [DomainControllerName], CN=Configuration,DC=[ForestRootDomain], CN=Services, and CN=Windows NT.

3.            Right-click CN=Directory Service, and then click Properties.

4.            In the Attribute column, click tombstoneLifetime.

5.            Note the value in the Value column. If the value is <not set>, the default value is in effect as follows:

•             On a domain controller in a forest that was created on a domain controller running Windows Server 2003 with Service Pack 1 (SP1), the default value is 180 days.

•             On a domain controller in a forest that was created on a domain controller running Windows 2000 Server or Windows Server 2003, the default value is 60 days.

The Active Directory support files are listed below. These are the files that you specify a location for when you promote a server to a domain controller:

  • Ntds.dit (NT Directory Services): Ntds.dit is the core Active Directory database. This file on a domain controller lists the naming contexts hosted by that particular domain controller.
  • Edb.log: The Edb.log file is a transaction log. When changes occur to Active Directory objects, the changes are initially saved to the transaction log before they are written to the Active Directory database.
  • Edbxxxxx.log: This is auxiliary transaction logs that can be used in cases where the primary Edb.log file fills up prior to it being written to the Ntds.dit Active Directory database.
  • Edb.chk: Edb.chk is a checkpoint file that is used by the transaction logging process.
  • Res log files: These are reserve log files whose space is used if insufficient space exists to create the Edbxxxxx.log file.
  • Temp.edb: Temp.edb contains information on the transactions that are being processed.

Schema.ini: The Schema.ini file is used to initialize the Ntds.dit Active Directory database when a domain controller is promoted.

Before performing an upgrade, you should make sure the server’s installed software and hardware support Windows Server 2008. You can download tools for testing compatibility and documentation at the Windows Server Catalog Web site (http://www.windowsservercatalog.com/).

 

Microsoft Server operating systems from Windows 2000 and later can be upgraded to Windows Server 2008. In general, servers can be upgraded to a product with equal or greater capabilities, thus:

 

  • Windows Server 2003 Standard or Enterprise editions can be upgraded to Standard or Enterprise editions of Windows Server 2008.
  • Windows Server 2003, Datacenter Edition, can be upgraded to Windows Server 2008 Datacenter.
  • Windows Server 2003, Web Edition, can be upgraded Windows Web Server 2008.
  • Windows Server 2008 Standard can be upgraded to Enterprise or Datacenter editions of Windows Server 2008.
  • Windows Server 2008 Enterprise can be upgraded to Windows Server 2008 Datacenter.

Windows Server 2008 provides several categories of events that you can audit, as described in the following list:

 

■ Account Logon Events:  Track user logon and logoff via a user account.

■ Account Management:  Track when a user account or group is created, changed, or

deleted; a user account is renamed, enabled, or disabled; or a password is set or changed.

■ Directory Service Access:  Track access to Active Directory.

■ Logon Events:  Track nonlocal authentication events such as network use of a resource or a remote

service that is logging on by using the local system account.

■ Object Access:  Track when objects are accessed and the type of access performed—for example,

track use of a folder, file, or printer. Configure auditing of specific events through the object’s

properties (such as the Security tab for a folder or file).

■ Policy Change:  Track changes to user rights or audit policies.

■ Privilege Use:  Track when a user exercises a right other than those associated with logon and

logoff.

■ Process Tracking:  Track events related to process execution, such as program execution.

■ System Events:  Track system events such as restart, startup, shutdown, or events that affect

system security or the security log.

A good security step to take to prevent hackers and others from making unauthorized changes to a system’s registry is to prevent remote access to a system’s registry. When a user attempts to connect to a registry remotely, Windows Server 2008 checks the ACL for the following registry key:

 

HKLM\System\ControlSet001\Control\SecurePipeServers\winreg

 

If this key is missing, all users can access the registry subject to the permissions assigned to individual keys. If the key exists, Windows Server 2008 checks the permissions on the key to determine whether or not the remote user can gain access to the registry (and levels of access). Individual keys then determine what these remote users can do with a given key. Therefore, winreg is the first line of defense, and individual key ACLs are the second line of defense. If you want to prevent all remote access to the registry, make sure you set the permissions on the winreg key accordingly.

Blade computing introduces a new data center paradigm where various thin compute blades share centralized resources in a single chassis. Ablade server is a single circuit board populated with components such as memory, processors, I/O adapters, and network connections that are often found on multiple boards. Server blades are built to slide into existing servers. They are smaller, need less power, and are more cost-efficient than traditional box-based servers.

 

Managing these servers requires the following:

  • A virtualized view of the servers and resources it uses (such as storage)
  • A high level of security within the server and on the network devices
  • Dynamic resource provisioning that is automated as much as possible
  • A layout that is easy to scale to meet ever-increasing user demands

Data centers will realize a shift from box-based servers to densely packed racks of blade-based servers.