Using 32-bit and 64-bit versions of the MMC

Posted: August 9, 2011 in Active Directory, Commands, Server, Server 2008, System Information
Tags: , , , , ,
0

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.

Kerberos Troubleshooting Tools

Posted: August 1, 2011 in Active Directory, Security, Server 2008, System Information
Tags: , , ,
2

Windows Server 2008 provides several tools that can be used when troubleshooting Kerberos Authentication

 

Klist.exe: Kerberos List: This tool is installed on Windows Server 2008 domain controllers and is available for download as part of the Windows Server 2003 Resource Kit tools.

 

Kerberos List is a command-line tool that is used to view and delete Kerberos tickets granted to the current logon session. To use Kerberos List to view tickets, you must run the tool on a computer that is a member of a Kerberos realm.

 

Kerbtray.exe: Kerberos Tray: Kerberos Tray is available for download as part of the Windows Server 2003 Resource Kit tools.

 

Kerberos Tray is a graphical user interface tool that displays ticket information for a computer running Microsoft’s implementation of the Kerberos version 5 authentication protocols. You can view and purge the ticket cache by using the Kerberos Tray tool icon located in the notification area of the desktop. By positioning the cursor over the icon, you can view the time left until the initial TGT expires. The icon also changes in the hour before the Local Security Authority (LSA) renews the ticket.

 

Tokensz.exe: Kerberos Token Size: Kerberos Token Size is available for download from the Microsoft download center.

 

You can use Kerberos Token Size to verify if the source of the Kerberos errors stems from a maximum token size issue. The tool will simulate an authentication request and report the size of the resulting Kerberos token. The tool will also report the maximum supported size for the token.

 

Setspn.exe: The Setspn utility is installed on Windows Server 2008 domain controllers and is included in the Windows Server 2003 Support Tools.

 

The Setspn utility allows you to read, modify, and delete the Service Principal Names (SPN) directory property for an Active Directory service account. Because SPNs are security-sensitive, you can only set SPNs for service accounts if you have domain administrator privileges.

 

Ksetup.exe: The Ksetup utility is installed on Windows Server 2008 domain controllers and is included in the Windows Server 2003 Support Tools.

 

The Ksetup utility configures a client connected to a server running Windows Server 2008 to use a server running Kerberos V5. The client then uses a Kerberos V5 realm instead of a Windows Server 2008 domain.

 

Ktpass.exe: The Ktpass utility is installed on Windows Server 2008 domain controllers and is included in the Windows Server 2003 Support Tools.

 

The Ktpass utility is used to configure a non–Windows Server Kerberos service as a security principal in the Windows Server 2008 AD DS.

 

W32tm.exe: Windows Time: This tool is included in Microsoft Windows server and client operating systems.

 

W32tm.exe is used to configure Windows Time service settings. It can also be used to diagnose problems with the time service.

Intrasite and Intersite Replication

Posted: August 1, 2011 in Active Directory, Server 2008, System Information
Tags: , , , ,
4

The description of how AD DS replication works applies to both intrasite and intersite replication. In both cases, the domain controllers use the same processes to optimize the replication process. However, one of the main reasons to create additional sites in AD DS is to manage replication traffic. Because all of the domain controllers within a site are assumed to be connected with fast network connections, replication between these domain controllers is optimized for maximum speed and reduced latency. However, if the replication traffic has to cross a slow network link, conserving network bandwidth is a much more significant issue. Creating multiple sites allows for this conservation of network bandwidth by enabling features such as data compression and scheduled AD DS replication.

 

Intrasite Replication

 

The primary goal for replication within a site is to reduce replication latency, that is, to make sure that all domain controllers in a site are updated as quickly as possible. To accomplish this goal, intrasite replication traffic has the following characteristics:

 

  • The replication process is initiated by a notification from the sending domain controller. When a change is made to the database, the sending computer notifies a destination domain controller that changes are available. The changes are then pulled from the sending domain controller by the destination domain controller using a remote procedure call (RPC) connection. After this replication is complete, the domain controller notifies another destination domain controller, which then pulls the changes. This process continues until all the replication partners have been updated.
  • Replication occurs almost immediately after a change has been made to the AD DS information. By default, a domain controller will wait for 15 seconds after a change has been made and then begin replicating the changes to other domain controllers in the same site. The domain controller will complete replication with one partner, wait 3 seconds, and then initiate replication with another partner. The reason the domain controller waits 15 seconds after a change is to increase the efficiency of the replication in case additional changes are made to the partition information.
  • The replication traffic is not compressed. Because all the computers within a site are connected with fast network connections, the data is sent without compression. Compressing the replication data adds an additional load on the domain controller server. Uncompressed replication traffic preserves server performance at the expense of network utilization.
  • Replication traffic is sent to multiple replication partners during each replication cycle. Whenever a change is made to the directory, the domain controller will replicate the information to all direct replication partners, which might be all or some of the other domain controllers in the site.

 

Intersite Replication

 

The primary goal of replication between sites is to reduce the amount of bandwidth used for replication traffic. This means that intersite replication traffic has the following characteristics:

 

  • Replication is initiated according to a schedule rather than when changes are made. To manage replication between sites, you must configure a site link connecting the two sites. One of the configuration options on the site link is a schedule for when replication will occur. Another is the replication interval setting for how often replication will occur during the scheduled time. If the bandwidth between company locations is limited, the replication can be scheduled to happen during nonworking hours.
  • Replication traffic is compressed down to about 40 percent of the noncompressed size when replication traffic is more than 32 KB in size. To save bandwidth on the network connection, the bridgehead servers in each site compress the traffic at the expense of additional CPU usage.
  • Notifications are not used to alert a domain controller in another site that changes to the directory are available. Instead, the schedule determines when to replicate. Note You can disable compression for intersite replication and enable notifications.
  • Intersite replication connections can use either an Internet Protocol (IP) or a Simple Mail Transfer Protocol (SMTP) transport. SMTP can be used as a transport protocol only for the configuration, schema, and application directory partitions, not for the domain partition. The connection protocol you use is determined by the available bandwidth and the reliability of the network that connects company locations.
  • Replication traffic is sent through bridgehead servers rather than to multiple replication partners. When changes are made to the directory in one site, the changes are replicated to a single bridgehead server (per directory partition) in that site, and the changes are then replicated to a bridgehead server in the other site. The changes are replicated from the bridgehead server in the second site to all the domain controllers in that site.
  • You can easily modify the flow of replication between sites. Almost every component of intersite replication can be changed.

Encrypting File System in Server 2008

Posted: August 1, 2011 in Active Directory, Server 2008, System Information
Tags: , ,
2

The Encrypting File System (EFS) is one feature made possible by reparse points in Windows Server 2008 that enhances security for local files on NTFS volumes. EFS is useful for securing files on any system, but it is most useful on systems that can easily be stolen or physically compromised, such as notebook and tablet PCs. EFS is integrated within NTFS and therefore is applicable only to files on NTFS volumes. FAT16 and FAT32 volumes do not support EFS. Only files can be encrypted; folders cannot, even on NTFS volumes. However, folders are marked to indicate that they contain encrypted data. EFS are designed to protect files locally, and therefore don’t support sharing of encrypted files. You can store your own encrypted files on a remote server and access those files yourself. The data is not encrypted during transmission across the network, however, unless you use Internet Protocol Security (IPsec) to encrypt IP traffic (assuming you are using TCP/IP as the network protocol for transferring the file).

Auditing Printer Usage and Management

Posted: July 19, 2011 in Printers, Server 2008
Tags: ,
0

Windows Server 2008 enables you to track print job success and failure on a logical printer.

 

You can audit access and usage to a logical printer as follows:

 

  1. Select the printer you wish to audit for printing and management. Right-click and select Properties; then select the Security tab.
  2.  On the Security tab, click the advanced button, which launches the Access Control Setting dialog box for the   logical printer. Click the Auditing tab.
  3.  On the Auditing tab, click Add and select the group or groups you want to access. Choose the Success or Failure audits you want to trap and click Apply.

 

That’s all there is to auditing printer usage. To check the audits, refer to the system log in Event Viewer.

Exchange Internet Protocol Access Components

Posted: July 19, 2011 in Exchange Server, System Information
Tags:
0

Exchange Server 2003 comes with a set of four Internet protocol services. These let you extend the reach of Exchange users beyond Microsoft’s very good, but proprietary, electronic messaging protocol MAPI. The four services are Hypertext Transmission Protocol (HTTP), which supports Outlook Web Access (OWA); Post Office Protocol (POP3); Internet Message Access Protocol (IMAP4); and Network News Transfer Protocol (NNTP):

 

HTTP:  HTTP is the core protocol that supports web access. OWA uses the HTTP protocol to give users access to everything in their Exchange mailboxes, as well as items in public folders, using a web browser such as Microsoft Internet Explorer. On the server side, OWA is supported by Windows Server 2003s Internet Information Server.

 

POP3 Server:  Exchange Servers POP3 server gives users with standard POP3 e−mail clients, such as Eudora or Outlook Express, limited access to their Exchange mailboxes. Users can download mail from their Exchange Inboxes, but that’s all. Users have no direct access to other personal or public information stores or to their schedules. This is due to limitations in the POP3 protocol itself, not in Microsoft’s implementation of the protocol.

 

IMAP4 Server:  The Exchange IMAP4 server goes one better than POP3, adding access to folders in addition to the Exchange Inbox. With IMAP4, folders and their contents can remain on the Exchange server, be downloaded to the computer running your IMAP4 client, or both. You can keep Exchange Server based folders and their contents in sync with the folders on an IMAP4 client.

 

NNTP Server:  The NNTP server lets you bring all those exciting Usenet newsgroups into your Exchange servers public folders, where your users can read and respond to them with the same e− mail clients that they use to read other public folders.

How to Restore the System State on a Domain Controller

Posted: July 11, 2011 in Active Directory, Server, Server 2003, Server 2008, System Information
Tags: , , ,
0

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.

Active Directory Intersite Replication

Posted: July 5, 2011 in Active Directory, Server, Server 2003, Server 2008
Tags: , , ,
4

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.

What is ADSIEdit?

Posted: July 5, 2011 in Active Directory, Server, Server 2003
Tags: , ,
0

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.

Determine the tombstone lifetime for the forest

Posted: July 5, 2011 in Active Directory, Server, Server 2003
Tags: , ,
0

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.

Older Entries
Newer Entries