Daily IT Matters, this is the place where I post my daily findings on IT.

Saturday, September 30, 2006

EVENT ID 12317

We’ve seen numerous reports of the following event within Microsoft and from our customers.
EVENT LOG Application
EVENT TYPE Warning
SOURCE SRMSVC
EVENT ID 12317
COMPUTERNAME SERVER2
TIME 5/1/2006 12:15:45 PM
MESSAGE File Server Resource Manager failed to enumerate share paths or DFS paths. Mappings from local file paths to share and DFS paths may be incomplete or temporarily unavailable. FSRM will retry the operation at a later time.
Error-specific details:
Error: (0x80070005) Access is denied.
Although this event doesn’t affect quota functionality, the fact that it occurs hourly has prompted numerous support calls from customers. We’ve isolated the cause and the solution for this event…well, most of the cause anyway.
An Event 12317 showing access denied is caused when the NT AUTHORITY\Authenticated Users group is not a member of the BUILTIN\Users group in the domain. (As you might know, the local BUILTIN\Users group on a domain controller is mapped to the domain built-in group Users. Therefore, the effect of removing NT AUTHORITY\Authenticated Users from the BUILTIN\Users group on a domain controller has a domain-wide effect.)
Why does this cause the event error? Because the DFS RPC endpoint is configured to allow both BUILTIN\Administrators access and BUILTIN\Users access, the latter of which is assumed to contain NT AUTHORITY\Authenticated Users (the default setting). Without NT AUTHORITY\Authenticated Users in the mix, the NetDfsEnum API fails to enumerate the domain-based roots because the FSRM service is authenticating with that identity. The resulting ERROR_ACCESS_DENIED error causes the event to fire.
What we haven’t solved is why NT AUTHORITY\Authenticated Users would be removed from the BUILTIN\Users group. We’ve looked for Active Directory guidance indicating this is a best practice, but we couldn’t find any. We suspect that admins might intentionally remove this group in an attempt to increase security.
So, to resolve this event, add NT AUTHORITY\Authenticated Users to BUILTIN\Users group on the PDC emulator. You can check this by launching Active Directory Users and Computers and looking in the Builtin folder for the domain. The Users group must contain the Authenticated Users group. If it does not, you can add it using the snap-in. Next, stop and restart the FSRM-related services (srmreports and srmsvc) on the file servers where FSRM is running.

 

Friday, September 29, 2006

SBS 11 tips for Home use

  1. Back up your important user data first.
  2. Purchase an external USB2 or IEEE 1394 (Firewire) hard drive and use it to back up important data from all your client systems. Afterward, you can use this drive for migrating data to the server and eventually it will become your backup drive for automatic server backups.
  3. Plan your network design. Take a look at the whitepaper "Understanding Your Network" on TechNet online (the link can be found in the "Additional Resources" sidebar) and choose the deployment scenario that best fits your home network design.
  4. Plan your external connectivity. If you want to set up your own Web site or receive external e-mail at your server, register a domain name. You might need to sign up with a DNS registration service like ZoneEdit or DynDNS if your Internet provider uses dynamic IP addressing.
  5. Plan your server. It doesn't take much to run a decent SBS server for a home environment. You'll need at least 512MB of RAM, two hard drives (small operating system drive and larger disk for user data), one or two NICs, UPS battery backup, and the removable hard drive mentioned earlier.
  6. Plan the domain details. Choose a domain name for your Active Directory—in other words, your Windows domain name. Figure out how many user accounts you need and what they'll be called. Decide what role each user will have in the domain. Choose a naming plan for servers, clients, and other resources.
  7. Use the wizards as much as possible. The wizards in SBS are your friends and should be the first course of action for anything using built-in features. They'll save you much time and hassle.
  8. Upgrade clients. If possible, upgrade your client operating systems to Windows XP Professional. SBS really shines when it's the heart of your domain. Windows XP SP2 is our recommended baseline until Windows Vista™ is available. Home editions and Windows 9x simply cannot join the domain.
  9. Enhance or expand your server as necessary. One big benefit of SBS is that it can be expanded in just about any way a Windows system can, but we suggest you try to keep it to processes that can be run as a service. Otherwise, you'll need to log onto the server and run applications after every reboot.
  10. Read the performance reports. We regularly (about once a week) scan through the performance reports and resolve any recurring problems or trends.
  11. Engage the SBS community. SBS has a vibrant community of MVPs, enthusiasts, and operating partners. See the links in the "Additional Resources" sidebar for a number of online sources of information and support. If you get stumped or have a problem, post it to the newsgroup. Chances are someone else has experienced the same issue and has a fix or workaround for your situation.

 

Managing Exchange 2003 with WMI, Part 1

Like most Windows products released in 2003, Exchange Server 2003 offers more manageability through Windows Management Instrumentation (WMI). As Table 1 (http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 40755) shows, Exchange 2000 Server was the first release in which Microsoft implemented WMI interfaces for Exchange. The original release offered three WMI providers: ExchangeRoutingTableProvider, ExchangeQueueProvider, and ExchangeClusterProvider. These providers are available from the Root\CIMV2\Applications\Exchange namespace. Later, Microsoft released Exchange 2000 Service Pack 2 (SP2), which introduced two new WMI providers in the Root\MicrosoftExchangeV2 namespace: ExchangeDsAccessProvider and ExchangeMessageTrackingProvider.

Little difference exists between the five providers in Exchange 2000 SP2 and those same five providers in Exchange 2003. The only noticeable change is that Microsoft updated the ExchangeMessageTrackingProvider's Exchange_MessageTrackingEntry class by adding values to the class's EntryType property. To view the documentation on the EntryType property's possible values, go to the Microsoft Developer Network (MSDN) Web site at http://msdn.microsoft.com/library/en-us/e2k3/e2k3/_wmiref_pr_exchange_messagetrackingentryentrytype.asp.

In addition to the five WMI providers found in Exchange 2000 SP2, Exchange 2003 offers five new WMI providers in the Root\MicrosoftExchangeV2 namespace: ExchangeFolderTreeProvider, ExchangeMapiTableProvider, ExchangePublicFolderProvider, ExchangeQueue2Provider, and ExchangeServerProvider. So, when you install Exchange 2003, you're installing a total of 10 WMI providers, which support more than 20 WMI classes in various management areas of Exchange 2003.

Any WMI consumer (i.e., any application that can access and use WMI data) can use the WMI classes that the Exchange 2003 installation adds to the Common Information Model (CIM) repository. Therefore, a Windows Script Host (WSH) script, a WMI event consumer provider (e.g., SMTP permanent event consumer), or enterprise-management software (e.g., HP OpenView Operations for Windows) can act as a WMI consumer. Let's look at how to use WSH scripts to access and use the Exchange 2003 WMI management information. I discuss only the new providers that Exchange 2003 adds. I won't discuss the five original Exchange WMI providers because they're well documented. If you're interested in more details, see the Microsoft article "Automating Exchange 2000 Management with Windows Script Host" (http://www.microsoft.com/technet/prodtechnol/exchange/2000/maintain/ex2kwsh.mspx). For the same reason, I won't cover WMI basics. If you're unfamiliar with WMI, check out the references at http://msdn.microsoft.com/library/en-us/wmisdk/wmi/further_information.asp.

Exchange 2003's five new providers support 15 new WMI classes. These providers and their classes fall into the following categories:•
Exchange server management

Exchange logon management

Exchange mailboxes

Exchange public folders and folder tree management

Exchange SMTP and X400 queues management

Because these categories cover a lot of material, I'm splitting this article into three parts. I'll cover the first three categories in Part 1, the fourth category in Part 2, and the fifth category in Part 3.
Top of page
Exchange Server Management

For Exchange server management tasks, you use the ExchangeServerProvider. This provider supports the Exchange_Server class, which let's you retrieve information about an Exchange 2003 server, such as the server's Administrative Group or Exchange version.

Let's begin by looking at how you use the Exchange_Server class to perform a simple task: obtaining a list of all the available Exchange servers in an organization. The article "Exchange 2000 SP2 WMI Updates," January 2003, http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 27211, includes a script named GetCollectionOfInstances.wsf, which uses a WMI Query Language (WQL) query to list all instances of a class. If you run the command
GetCollectionOfInstances.wsf
"Select * From Exchange_Server"
/NameSpace:Root\MicrosoftExchangeV2

from the command-shell window, you can obtain a list of all the available Exchange servers in your organization. Note that the script shows only those properties that have a value. Figure 1 (http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 40755) shows sample data from running GetCollectionOfInstances.wsf against the Exchange_Server class.

FIGURE 1: Sample Exchange_Server class output
C:\>GetCollectionOfInstances.wsf "Select * From Exchange_Server"
/Namespace:root\MicrosoftExchangeV2
/Machine:VM10284346B.LissWare.Net
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

AdministrativeGroup: ..................... Second Administrative Group
CreationTime: ............................ 20030731154649.000000+000
DN: ...................................... CN=VM10284346F,CN=Servers,
CN=Second Administrative Group,
CN=Administrative Groups,
CN=LissWareNET,CN=Microsoft Exchange,
CN=Services,
CN=Configuration,DC=LissWare,DC=NET
ExchangeVersion: ......................... Version 6.5 (Build 6944.4)
*FQDN: ................................... VM10284346F.LissWare.NET
GUID: .................................... {0B5A401B-832F-444B-8984-7FAEE70579C8}
IsFrontEndServer: ........................ FALSE
LastModificationTime: .................... 20030731155613.000000+000
MessageTrackingEnabled: .................. FALSE
MessageTrackingLogFileLifetime: .......... 7
MessageTrackingLogFilePath: .............. C:\Program Files\Exchsrvr\VM10284346F.log
MonitoringEnabled: ....................... TRUE
MTADataPath: ............................. C:\Program Files\Exchsrvr\mtadata
Name: .................................... VM10284346F
RoutingGroup: ............................ First Routing Group
SubjectLoggingEnabled: ................... FALSE
Type: .................................... 1
AdministrativeGroup: ..................... First Administrative Group
CreationTime: ............................ 20030720180526.000000+000
DN: ...................................... CN=VM10284346B,CN=Servers,
CN=First Administrative Group,
CN=Administrative Groups,
CN=LissWareNET,CN=Microsoft Exchange,
CN=Services,
CN=Configuration,DC=LissWare,DC=NET
ExchangeVersion: ......................... Version 6.5 (Build 6944.4)
*FQDN: ................................... VM10284346B.LissWare.NET
GUID: .................................... {A70378F2-9689-4AA8-B729-AC9DF8A59F98}
IsFrontEndServer: ........................ FALSE
LastModificationTime: .................... 20030720181104.000000+000
MessageTrackingEnabled: .................. FALSE
MessageTrackingLogFileLifetime: .......... 7
MessageTrackingLogFilePath: .............. C:\Program Files\Exchsrvr\VM10284346B.log
MonitoringEnabled: ....................... TRUE
MTADataPath: ............................. C:\Program Files\Exchsrvr\mtadata
Name: .................................... VM10284346B
RoutingGroup: ............................ First Routing Group
SubjectLoggingEnabled: ................... FALSE
Type: .................................... 1

You can download GetCollectionOfInstances.wsf as well as all the other scripts discussed in this article from the Exchange & Outlook Administrator Web site. Go to http://www.winnetmag.com/microsoftexchangeoutlook, enter InstantDoc ID 40755 in the InstantDoc ID box, then click Download the Code. To run GetCollectionOfInstances.wsf and the other scripts in this article, you must have Administrator permission if the namespace is accessed remotely or user permission if you access the namespace locally. If you use the user permission, make sure you can log on locally to the server.

Although learning about an Exchange server is interesting, being able to update that information would be more helpful. Using the Exchange_Server class's four read/write properties (i.e., AdministrativeNote, Message-TrackingLogFileLifetime, MonitoringEnabled, and SubjectLoggingEnabled) and two methods (i.e., MoveMTAData and EnableMessageTracking), you can do just that. For example, let's look at how you can use the AdministrativeNote property to update an Exchange server's administrative note and the EnableMessageTracking method to enable message tracking on an Exchange server.

Using the AdministrativeNote property. The script AdminNote.wsf, which Listing 1 shows, is a Windows Script (WS) file that leverages the AdministrativeNote property and the XML features that WSH 5.6 provides. The script uses the TinyErrorHandler.vbs file, which contains the ErrorHandler function. This function helps handle errors that occur during script execution.

Next, AdminNote.wsf creates an SWbemLocator object, which the script uses for the WMI connection. As the code at callout A in Listing 1 shows, the script uses a user ID and password to complete the WMI connection. When the user ID and password are empty strings, the script makes the connection under the security context of the user who's running the script. If you need to run the script under a different security context, you can add a user ID and password in the code at callout A.

Callout A highlights two additional lines that you must customize before you run AdminNote.wsf. First, you must change the cComputerName constant's value to the Fully Qualified Domain Name (FQDN) of an Exchange computer in your organization. In addition, you'll probably want to change the cAdministrativeNote constant's string to a more suitable administrative note.

After establishing the WMI connection, AdminNote.wsf uses the cComputerName constant's FQDN to retrieve an instance of the Exchange_Server class. This instance represents an Exchange 2003 server and its set of information (e.g., the Administrative Group, Exchange version, message-tracking status). Next, the script displays the current value of the AdministrativeNote property, after which it replaces that value with the value assigned to the cAdministrativeNote constant. The script then updates the Exchange_Server instance by invoking the Put_method, which the SWbemObject exposes. (If you're unfamiliar with the SWbemLocator or SWbemObject objects, you can learn about them at http://msdn.microsoft.com/library/en-us/wmisdk/wmi/scripting_api_objects.asp.) After the script saves the instance, the change is visible in Exchange System Manager (ESM).

You can adapt AdminNote.wsf to update the other read/write properties of the Exchange_Server class. Only the name of the property to update and its respective data type will vary (e.g., string data versus Boolean data when appropriate). Callout B in Listing 1 highlights the line to change to read a different property. Callout C in Listing 1 highlights the line to change to update a different property.AdminNote.wsf is a simple script that demonstrates a structure that's common to most of the WSH WMI scripts in this article. Therefore, I discuss only variations of this structure that won't be familiar to you.

Using the EnableMessageTracking method. The EnableMessageTracking method lets you enable or disable message tracking on an Exchange server. The script MessageTracking.wsf, which Listing 2 shows, illustrates how to use the EnableMessageTracking method. The overall logic of the code is basically the same as that in AdminNote.wsf. The major change resides in the method invocation. As the code at callout B in Listing 2 shows, the EnableMessageTracking method requires two parameters. The first parameter is a Boolean value that enables (True=Enabled) or disables (False=Disabled) message tracking. The second parameter is a string that specifies the message-tracking log's pathname. The script uses constants (cMessageTrackingEnabled and cMessageTrackingLogFilePath, respectively) to provide both of these parameters.

If you want to use this script, you need to customize the cMessageTrackingEnabled and cMessageTrackingLogFilePath constants as well as the other constants that callout A in Listing 2 highlights. If you want to use the MoveMTAData method to move Message Transfer Agent (MTA) files to another location, you can adapt MessageTracking.wsf by changing the invoked method and the input parameters. You can find the documentation for both methods at http://msdn.microsoft.com/library/en-us/e2k3/e2k3/_wmiref_cl_exchange_server.asp.
Top of page
Exchange Logon Management

For Exchange logon management tasks, you use the ExchangeMapiTableProvider. This provider supports the Exchange_Logon class, which represents the users currently logged on to an Exchange 2003 server. The Exchange_Logon class has a set of read-only properties and doesn't have any method. The documentation for the properties is available from Microsoft at http://msdn.microsoft.com/library/enus/e2k3/e2k3/_wmiref_cl_exchange_logon.asp. You can use GetCollectionOfInstances.wsf with the WQL query
"Select * From Exchange_Logon"

to obtain a list of all instances and properties of the Exchange_Logon class. You can limit the scope of the query to a specific mailbox by specifying the mailbox's display name. To do so, you use the Where statement in a WQL query, such as
"Select * From Exchange_Logon
Where MailboxDisplayName=
'LISSOIR Alain'"

Figure 2 shows sample data from running this query.

FIGURE 2: Sample Exchange_Logon class output
C:\>GetCollectionOfInstances.wsf "Select * From Exchange_Logon
Where MailboxDisplayName='LISSOIR Alain'"
/Machine:vm10284346b.LissWare.Net
/NameSpace:root\MicrosoftExchangeV2
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

AdapterSpeed: ............................ 10000
ClientIP: ................................ 192.10.10.1
ClientMode: .............................. 2
ClientName: .............................. VM10284346A.LissWare.NET
ClientVersion: ........................... 11.0.5329.6
CodePageID: .............................. 1252
FolderOperationRate: ..................... 0
LastOperationTime: ....................... 20030804213440.000325+***
Latency: ................................. 0
LocaleID: ................................ 1033
LoggedOnUserAccount: ..................... VMLISSWARENET\alain.lissoir
LoggedOnUsersMailboxLegacyDN: ............ /o=LissWareNET
/ou=First Administrative Group
/cn=Recipients/cn=alain.lissoir
LogonTime: ............................... 20030804213440.000325+***
MacAddress: .............................. 00-0C-29-21-A4-91
MailboxDisplayName: ...................... LISSOIR Alain
MailboxLegacyDN: ......................... /o=LissWareNET
/ou=First Administrative Group
/cn=Recipients/cn=alain.lissoir
.
.
*ServerName: ............................. VM10284346B
*StorageGroupName: ....................... First Storage Group
*StoreName: .............................. Mailbox Store (VM10284346B)
StoreType: ............................... 1
StreamOperationRate: ..................... 0
TableOperationRate: ...................... 0
TotalOperationRate: ...................... 0
TransferOperationRate: ................... 0

AdapterSpeed: ............................ 10000
ClientIP: ................................ 192.10.10.1
ClientMode: .............................. 2
ClientName: .............................. VM10284346A.LissWare.NET
ClientVersion: ........................... 11.0.5329.6
CodePageID: .............................. 1252
FolderOperationRate: ..................... 3
LastOperationTime: ....................... 20030805073649.000212+***
Latency: ................................. 3195
LocaleID: ................................ 1033
LoggedOnUserAccount: ..................... VMLISSWARENET\alain.lissoir
LoggedOnUsersMailboxLegacyDN: ............ /o=LissWareNET
/ou=First Administrative Group
/cn=Recipients/cn=alain.lissoir
LogonTime: ............................... 20030805073623.000381+***
MacAddress: .............................. 00-0C-29-21-A4-91
MailboxDisplayName: ...................... LISSOIR Alain
MailboxLegacyDN: ......................... /o=LissWareNET
/ou=First Administrative Group
/cn=Recipients/cn=alain.lissoir
.
.
*ServerName: ............................. VM10284346B
*StorageGroupName: ....................... First Storage Group
*StoreName: .............................. Public Folder Store (VM10284346B)
StoreType: ............................... 2
StreamOperationRate: ..................... 2
TableOperationRate: ...................... 17
TotalOperationRate: ...................... 41
TransferOperationRate: ................... 0

You can gather a lot of mailbox and user information from this output. For example, you can learn about the user account (LoggedOnUserAccount property) that's connected to the mailbox, the store to which the user is connected (StoreName property), the IP address of the client (ClientIP property), and the client software version (ClientVersion property), which corresponds to Microsoft Office Outlook 2003. Note that with earlier versions of Outlook and with Internet protocol-based clients such as Outlook Express, not all properties are initialized. For nonMessaging API (non-MAPI) clients, the client version might be SMTP or OLE DB. You can have more than one connection listed in the output. For example, you can have two connections: one to the mailbox store and one to the public folder store. The output often shows several Exchange_Logon instances for one client. Therefore, to be exact, the Exchange_Logon class represents the client connections more than it represents the client logons, even if it presents some logon information, such as the LogonTime property.

Although the output in Web Figure 2 is useful for tracking messages, tracking user logons only when users log on to Exchange can be more revealing. To show the properties of the Exchange_Logon class only at that time, you must use a different WQL query, called a WQL event query. "Exchange 2000 SP2 WMI Updates" provides a script called GenericEventAsyncConsumer.wsf that submits such a query. Therefore, to obtain the same information as before but only at logon time, you use the WQL query
"Select * From
__InstanceOperationEvent
Within 10 Where
TargetInstance ISA
'Exchange_Logon' And
TargetInstance.MailboxDisplayName=
'LISSOIR Alain'"
with GenericEventAsyncConsumer.wsf.
Top of page
Exchange Mailbox Management

For Exchange mailbox management tasks, you use the ExchangeMapiTableProvider's Exchange_Mailbox class. This class provides a series of read-only properties and two methods (i.e., Purge and Reconnect) that you can use to manage mailboxes. The documentation for the Exchange_Mailbox properties and methods is at http://msdn.microsoft.com/library/en-us/e2k3/e2k3/_wmiref_cl_exchange_mailbox.asp.

Some of the Exchange_Mailbox properties return mailbox-related information, such as the last logon time (LastLogonTime property), the last logoff time (LastLogoffTime property), and the name of the last user who logged on to the mailbox (LastLoggedOnUserAccount property). Other Exchange_Mailbox properties provide information about the mailbox location on the Exchange server. This information includes the server name (ServerName property), storage group (SG) name (StorageGroupName property), and store name (StoreName property). The Exchange_Mailbox class also exposes information about the size (in bytes) of a mailbox (Size property) and the number of items in the mailbox (TotalItems property).

The Purge and Reconnect methods' roles relate to fixing orphaned mailboxes. (You must handle other mailbox management tasks, such as creating, moving, or deleting an Exchange mailbox, through Collaboration Data Objects for Exchange Management—CDOEXM.) If an administrator uses the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to delete a user account but doesn't delete the mailbox, the mailbox is left in a disconnected state. After Exchange's Cleanup Agent runs, the mailbox in the Exchange Mailbox store is left without a user assigned to it. At that time, Exchange gives the administrator the chance to physically delete the mailbox from the store, which is the aim of the Purge method, or to reconnect the mailbox to an existing user, which is the aim of the Reconnect method.

The script Reconnect.wsf demonstrates how to use the Reconnect method to reconnect an Exchange mailbox to an existing user account. The structure of Reconnect.wsf is similar to that of AdminNote.wsf. However, slight differences exist. The script header starts with the definition of two constants: cMailboxDisplayName, which specifies the display name of the mailbox to reconnect, and cUserAccount, which specifies the user account to which to reconnect the mailbox.

To locate the mailbox, the script uses a WQL query, such as
"Select * From Exchange_Mailbox
Where MailboxDisplayName=
'LISSOIR Alain'"

After this query executes, the script enumerates a collection of mailboxes that match the selection criterion. In other words, the script isolates the mailbox by using a property whose value isn't guaranteed to be unique. Although you could specify the mailbox's globally unique identifier (GUID), which is guaranteed to be unique, in the MailboxGUID property, using the mailbox's display name is easier. Trying to find a mailbox's GUID, then trying to enter it without an error, would make the script difficult to use.

Because the mailbox name might not be unique, the script checks to see whether the collection contains only one mailbox, as the code excerpt in Listing 3 shows. If the script finds more than one mailbox, it displays a message that informs the operator about the ambiguity. If the script finds only one mailbox, it executes the Reconnect method. This method has two required parameters, which the script supplies through the cMailboxDisplayName and cUserAccount constants.

Although the WQL query I just showed you finds the mailbox, you don't have any guarantee that the mailbox is disconnected from a user. To determine whether a mailbox is disconnected, you can use the Exchange_Mailbox class's DateDiscoveredAbsentInDS property. This property indicates when the store detected that the mailbox no longer had a corresponding user account. When this property contains a date in the Distributed Management Task Force (DMTF) format, it's a disconnected mailbox. For more information about the DMTF format, go to http://msdn.microsoft.com/library/enus/wmisdk/wmi/date_and_time_format.asp.

To locate a mailbox using a specific display name and to ensure that the mailbox is disconnected, you can use an improved WQL query that narrows the search's scope:
"Select * From Exchange_Logon
Where MailboxDisplayName=
'LISSOIR Alain' And
DateDiscoveredAbsentInDS
IS NOT Null"

Finally, to ensure a successful execution of the Reconnect method, you must follow these guidelines:•
Run the script on the Exchange server on which the disconnected mailbox resides. Even when WMI is Distributed COM (DCOM)based, running the script remotely causes the Reconnect method to fail.

Select a user ID that exists in AD by referencing the sAMAccountName of that user ID (which is the legacy logon name). If you specify a domain and username or a user principal name (UPN), the Reconnect method will fail. Only an sAMAccountName is accepted.

If you don't follow these guidelines, the Reconnect mailbox method will fail. You'll get the following error message: An unknown ADSI user object was requested. Make sure you have the required permissions and/or you are running on the Exchange Server to invoke this method.
Top of page
WMI and CDOEXM

The addition of WMI's providers and classes has improved object management in Exchange 2003. Some WMI classes provide information that you can also obtain with CDOEXM. Take, for example, WMI's Exchange_Server class. The Exchange_Server class's Name property and CDOEXM's Name property both provide the Exchange server's name. Similarly, the Exchange_Server class's ServerType property and CDOEXM's Type property both provide the server's type (i.e., back-end or front-end server). Other Exchange_Server class properties (e.g., the Exchange_Server class's MonitoringEnabled property) and methods (e.g., the Exchange_Server class's MoveMTAData method) nicely complement the CDOEXM features. And the addition of the ExchangeMapiTableProvider WMI provider to Exchange 2003 enhances the management of Exchange in two areas: user logon management and mailbox management. Although these two technologies expose a complementary (and sometimes redundant) set of information, both technologies contribute to the expansion of Exchange server manageability.TABLE 1: WMI Providers and Classes That Exchange 2003 and Exchange 2000 Introduced
Provider Name (Namespace) Provider Classes Description of Classes
Exchange 2003

ExchangeFolderTreeProvider (Root\MicrosoftExchangeV2)
Exchange_FolderTree
Provides information about public and private folder trees on Exchange MicrosoftExchangeV2) servers.

ExchangeMapiTableProvider (Root\MicrosoftExchangeV2)
Exchange_Logon
Represents the users currently logged on to Exchange.

Exchange_Mailbox
Returns information about Exchange mailboxes.

ExchangePublicFolderProvider (Root\MicrosoftExchangeV2)
Exchange_PublicFolder
Provides properties and methods for working with Exchange public folders.

Exchange_ScheduleInterval
Provides information about the start and stop time of the public folder replication schedule. Instances of this class are returned as members of an array from the ReplicationSchedule property, which the Exchange_PublicFolder class exposes.

ExchangeQueue2Provider (Root\MicrosoftExchangeV2)
Exchange_QueueCacheReloadEvent
Provides information about when the queue’s cache was reloaded.

Exchange_SMTPLink
Provides methods for controlling an SMTP Exchange Link. Inherits all the properties of the Exchange_Link class.

Exchange_X400Link
Provides methods for controlling a X400 Exchange Link. Inherits all its properties from the Exchange_Link class.

Exchange_QueueX400VirtualServer
Returns properties for X400 queue virtual servers. Inherits all its properties from the Exchange_QueueVirtualServer class.

Exchange_QueueSMTPVirtualServer
Returns properties for SMTP queue virtual servers. Provides two methods in addition to the properties it inherits from the Exchange_QueueVirtualServer class.

Exchange_QueuedX400Message
Provides methods to work with Exchange messages currently in an X400 queue.

Exchange_QueuedSMTPMessage
Provides methods to work with Exchange messages currently in an SMTP queue.

Exchange_SMTPQueue
Returns properties for SMTP queues. Inherits all its properties from the Exchange_Queue class.

Exchange_X400Queue
Returns properties for X400 queues. This class inherits all its properties from the Exchange_Queue class.

ExchangeServerProvider (Root\MicrosoftExchangeV2)
Exchange_Server
Provides properties and methods for working with Exchange servers.
Exchange 2000 SP2

ExchangeDsAccessProvider (Root\MicrosoftExchangeV2)
Exchange_DSAccessDC
Provides information about Active Directory (AD) and Exchange Server 5.5 domain controllers (DCs) that are accessible to the Exchange 2000 DSAccess service.

ExchangeMessageTrackingProvider Root\MicrosoftExchangeV2)
Exchange_MessageTrackingEntry
Provides information about events that have occurred to the message during the time it was under the control of the computer running Exchange 2000.
Exchange 2000

ExchangeClusterProvider (Root\CIMV2\Applications\Exchange)
ExchangeClusterResource
Returns information about an Exchange cluster resource.

ExchangeQueueProvider (Root\CIMV2\Applications/Exchange)
ExchangeLink
Returns information about message-handling links between mail servers. A link can contain zero or more ExchangeQueue objects, depending on the current message traffic along the link. In ESM, these links are called queues.

ExchangeQueue
Returns information about the dynamic queues created to transfer individual messages between mail servers. ExchangeQueue is part of ExchangeLink. ExchangeQueue objects aren’t the same as the queues that ESM lists.

ExchangeRoutingTableProvider (Root\CIMV2\Applications\Exchange)
ExchangeServerState
Returns information about the computer running Exchange 2000.

ExchangeConnectorState
Returns information about an Exchange connector.

Top of page
Listing 1: The script AdminNote.wsf
<?xml version="1.0"?>
<package>
<job>
<?job error="True" debug="True" ?>
<script language="VBScript" src=".\Functions\TinyErrorHandler.vbs" />
<object progid="WbemScripting.SWbemLocator" _
id="objWMILocator" reference="true"/>
<script language="VBscript">
<![CDATA[
Const cWMINameSpace = "root\MicrosoftExchangeV2"
' BEGIN CALLOUT A
Const cUserID = ""
Const cPassword = ""
Const cComputerName = "VM10284346B.LissWare.Net"
Const cAdministrativeNote = "This is my administrative note!"
' END CALLOUT A
On Error Resume Next

objWMILocator.Security_.AuthenticationLevel = _
wbemAuthenticationLevelDefault
objWMILocator.Security_.ImpersonationLevel = _
wbemImpersonationLevelImpersonate
Set objWMIServices = _
objWMILocator.ConnectServer(cComputerName, _
cWMINameSpace, cUserID, cPassword)
Set objWMIInstance = _
objWMIServices.Get _
("Exchange_Server.FQDN='" & cComputerName & "'")
If Err.Number Then ErrorHandler (Err)

' BEGIN CALLOUT B
WScript.Echo "Current Administrative Note is '" & _
objWMIInstance.AdministrativeNote & "'."
' END CALLOUT B

' BEGIN CALLOUT C
objWMIInstance.AdministrativeNote = cAdministrativeNote
WScript.Echo "Updated Administrative Note is '" & _
cAdministrativeNote & "'."
' END CALLOUT C

objWMIInstance.Put_ (wbemChangeFlagUpdateOnly Or _
wbemFlagReturnWhenComplete)
If Err.Number Then ErrorHandler (Err)
]]>
</script>
</job>
</package>
Top of page
Listing 2: The script MessageTracking.wsf
<?xml version="1.0"?>
<package>
<job>
<?job error="True" debug="True" ?>
<script language="VBScript" _
src=".\Functions\TinyErrorHandler.vbs" />
<object progid="WbemScripting.SWbemLocator" _
id="objWMILocator" reference="true"/>
<script language="VBscript">
<![CDATA[
Option Explicit
Const cWMINameSpace = "root\MicrosoftExchangeV2"
' BEGIN CALLOUT A
Const cUserID = ""
Const cPassword = ""
Const cComputerName = "VM10284346B.LissWare.Net"
Const cMessageTrackingEnabled = True
Const cMessageTrackingLogFilePath = _
"C:\Program Files\Exchsrvr\VM10284346B.log"
' END CALLOUT A
Dim objWMIServices
Dim objWMIInstance
On Error Resume Next

objWMILocator.Security_.AuthenticationLevel = _
wbemAuthenticationLevelDefault
objWMILocator.Security_.ImpersonationLevel = _
wbemImpersonationLevelImpersonate

Set objWMIServices = _
objWMILocator.ConnectServer(cComputerName, _
cWMINameSpace, cUserID, cPassword)
If Err.Number Then ErrorHandler (Err)
Set objWMIInstance = _
objWMIServices.Get _
("Exchange_Server.FQDN='" & cComputerName & "'")
If Err.Number Then ErrorHandler (Err)
WScript.Echo "Current Message Tracking status is '" & _
objWMIInstance.MessageTrackingEnabled & "'."
' BEGIN CALLOUT B
objWMIInstance.EnableMessageTracking _
cMessageTrackingEnabled, _
cMessageTrackingLogFilePath
' END CALLOUT B
If Err.Number Then ErrorHandler (Err)

Set objWMIInstance = Nothing
Set objWMIServices = Nothing
]]>
</script>
</job>
</package>
Top of page
Listing 3: Excerpt from Reconnect.wsf
If Err.Number Then ErrorHandler (Err)

Set objWMIInstances = objWMIServices.ExecQuery _
("Select * From Exchange_Mailbox" & _
" Where MailboxDisplayName='" & cMailboxDisplayName & "'")

If Err.Number Then ErrorHandler (Err)

If objWMIInstances.Count = 1 Then
For Each objWMIInstance in objWMIInstances
WScript.Echo "Reconnecting mailbox '" & _
cMailboxDisplayName & _
"' to '" & cUserAccount & "' user account ..."
objWMIInstance.Reconnect cUserAccount
If Err.Number Then ErrorHandler (Err)
WScript.Echo "Mailbox '" & cMailboxDisplayName &amp; _
"' reconnected to '" & cUserAccount & "'."
Next
Else
If objWMIInstances.Count = 0 Then
WScript.Echo "There is no mailbox with the '" & _
cMailboxDisplayName & "' display name ..."
Else
WScript.Echo "There is more than 1 mailbox with the '" & _
cMailboxDisplayName & "' same display name ..."
End If
End If

© 2004 Exchange & Outlook Administrator. All rights reserved.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

 

Deploy printers by using Group Policy

Print Management (Printmanagement.msc) can be used with Group Policy to automatically add printer connections to a computer's Printers and Faxes folder.

To do this, you use the Deploy with Group Policy dialog box to automatically add a printer connection setting to an existing Group Policy object (GPO) in Active Directory. When Group Policy processing runs on client computers, the printer connection settings are applied to the users or computers associated with the GPO. This is called deploying printer connections. Printers you deploy by using this method appear in the Deployed Printers object of Print Management tree when the print server they are connected to is being monitored.

This method of installing a printer is useful in a laboratory, classroom, or branch office setting where every computer in the room or office needs access to the same printer. It is also useful in large organizations, where computers and printers are often separated by function, workgroup, or department, such as marketing or human resources.

A printer connection that has been installed by using a per-user connection is available to the user no matter what computer the user logs on to in the network. A printer connection that has been installed by using a per-machine connection appears in the Printers and Faxes folder, ready for use by any user of that computer. Note:
Only per-user printer connections are supported on computers running Windows 2000. Per-machine printer connections are supported on computers running Windows XP or later.

To deploy printer connections using Group Policy, add the PushPrinterConnections.exe utility to a machine startup script (for per-machine connections) or to a user logon script (for per-user connections). The utility reads the printer connection settings made in the GPO and adds the printer connection. Important:
In order for the PushPrinterConnections.exe utility to work, you must update your Active Directory schema with the Windows Server 2003 R2 changes. For more information about these schema updates, see the Microsoft Web site (http://go.microsoft.com/fwlink?linkid=51166).

Once you deploy printer connection settings to a GPO, the PushPrinterConnections.exe utility will run on the client computers upon logon or restart. The utility reads the settings from the GPO and adds the deployed printer connections to the users or computers to which the GPO applies. You can reuse the GPO used to deploy per-user or per-machine printer connections. For more information about Group Policy and Printers, see Set Group Policy for Printers on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=50998).

It is a good idea to use the same GPO for deploying the printer connection settings and the PushPrinterConnections.exe computer startup or user logon script. This ensures that only users (or computers) that receive the printer connection settings will run the PushPrinterConnections.exe utility. Important:
The print server role must be installed and you must be a member of the Administrators group to perform these procedures. You must also have write access to the Group Policy object to use it to manage printers. Before you install printers by using Group Policy, you must have a GPO for your printer connections settings that is assigned to the appropriate users and computers. You can use the Group Policy Object Editor or Active Directory Users and Computers to create a GPO.

For more information about using Group Policy, see Enterprise Management with the Group Policy Management Console on the Microsoft Web site (http://go.microsoft.com/fwlink?linkid=22814).
To install printers to groups of users or computers by using Group Policy
1. Open the Administrative Tools folder, and then double-click Print Management.
2. In the Print Management tree, under the appropriate print server, click Printers.
3. In the results pane, right-click the printer you want to deploy, and then click Deploy with Group Policy.
4. In the Deploy with Group Policy dialog box, click Browse, and then choose a Group Policy object.
5. Click OK.
6. To assign the printer connection setting to the GPO, do one or both of the following:

• As a per-user setting, select the The users that this GPO applies to (per user) check box.
• As a per-machine setting, select the The computers that this GPO applies to (per machine) check box.

7.
Click Add.
8.
Repeat steps 3 to 6 to add the printer connection setting to another GPO.
9. Click OK.

To use the PushPrinterConnections.exe file
1. Using Group Policy Management console (gpmc.msc), right-click the GPO with your printer connections settings, and then click Edit.
2. In the Group Policy Object Editor tree, navigate to one following locations:

• If the printer connections are deployed per-machine, go to Computer Configuration, Windows Settings, Scripts (Startup/Shutdown).
• If the printer connections are deployed per-user, go to User Configuration, Windows Settings, Scripts (Logon/Logoff).

3. Right-click Startup or Logon, and then click Properties.
4. In the Logon Properties or Startup Properties dialog box, click Show Files.
5. Copy the PushPrinterConnections.exe file to this location and then close the window.
6. In the Logon Properties or Startup Properties dialog box, click Add.
7. Type PushPrinterConnections.exe in the Script Name box.
8. If you want to enable logging, type –log in the Script Parameters box. Log files are written to %windir%\temp\ppcMachine.log (for per-computer connections) and %temp%\ppcUser.log (for per-user connections) on the computer on which the policy is applied.
9. Click OK.

Note:
For per-computer connections, the printer connections will be added when the client computer restarts. For per-user connections, the printer connections will be added when the user logs on. If you remove the printer connection settings from the GPO, PushPrinterConnections.exe will remove the corresponding printers from the client computer on the next restart or user logon.

 

del.icio.us tags: , ,

 

What are Domain and Forest Trusts

What Are Domain and Forest Trusts?
Updated: March 28, 2003

In this section•
Trust Scenarios

Technologies Related to Trusts

Most organizations that have more than one domain have a legitimate need for users to access shared resources located in a different domain. Controlling this access requires that users in one domain can also be authenticated and authorized to use resources in another domain. To provide authentication and authorization capabilities between clients and servers in different domains, there must be a trust between the two domains. Trusts are the underlying technology by which secured Active Directory communications occur, and are an integral security component of the Windows Server 2003 network architecture.

When a trust exists between two domains, the authentication mechanisms for each domain trust the authentications coming from the other domain. Trusts help provide for controlled access to shared resources in a resource domain (the trusting domain) by verifying that incoming authentication requests come from a trusted authority (the trusted domain). In this way, trusts act as bridges that allow only validated authentication requests to travel between domains.

How a specific trust passes authentication requests depends on how it is configured; trust relationships can be one-way, providing access from the trusted domain to resources in the trusting domain, or two way, providing access from each domain to resources in the other domain. Trusts are also either nontransitive, in which case trust exists only between the two trust partner domains, or transitive, in which case trust automatically extends to any other domains that either of the partners trusts.

In some cases, trust relationships are automatically established when domains are created; in other cases, administrators must choose a type of trust and explicitly establish the appropriate relationships. The specific types of trusts used and the structure of the resulting trust relationships in a given trust implementation depend on such factors as how the Active Directory directory service is organized, and whether different versions of Windows coexist on the network.
Trust Scenarios

It is possible to create a number of different domain and forest trust configurations, depending on the Active Directory structure of the organization. Windows Server 2003 domains and forests can trust other Windows Server 2003 domains and forests, as well as Windows 2000 and Windows NT 4.0 domains. For example, trust configurations vary in nature and complexity in each of the following scenarios:
Trusts within a single Windows 2000 Server or Windows Server 2003 forest

By default, all domain trusts within a single Active Directory forest are two-way, transitive trusts. There are three types of transitive trusts that are used within a single Windows 2000 Server or Windows Server 2003 forest. The first is the tree-root trust, which is created by default when you create a new domain tree by using the Active Directory Installation Wizard. The two-way transitive nature of intra-forest trusts such as the tree-root trust allows all domains in one tree to trust all domains in any other tree within the same forest.

The second type of trust is a parent-child trust. It is created automatically when you create a new domain in an existing domain tree by using the Active Directory Installation Wizard. When a new child domain is created, a parent-child trust is established between the new domain and the domain that immediately precedes it in the namespace hierarchy.

The last type of trust that can be used between trees is a shortcut trust, and is used to speed up access times to resources in a domain that is deep within the tree hierarchy of another domain.
Trusts between two Windows Server 2003 forests

It is possible to extend the transitivity of domain trusts within a single Windows Server 2003 forest to another Windows Server 2003 forest by manually creating a one-way or two-way forest trust. A forest trust is a transitive trust between a forest root domain and a second forest root domain. A one-way forest trust allows all users in one forest to trust all domains in the other forest; a two-way forest trust forms a transitive trust relationship between every domain in both forests. The transitivity of forest trusts is limited to the two forest partners; the forest trust does not extend to additional forests trusted by either of the partners.
Trusts across Windows Server 2003 and Windows 2000 forests

Windows Server 2003 forest trusts cannot be created between a Windows Server 2003 forest and a Windows 2000 forest. You can, however, manually create a trust relationship between any domain in a Windows Server 2003 forest and any domain in a Windows 2000 forest by using one-way or two-way external trusts. External trusts are nontransitive and provide for access to resources in another domain outside the forest that is not already joined by a forest trust.
Trusts between Windows Server 2003 or Windows 2000 domains and Windows NT 4.0 domains

You can manually create a one-way or two-way external trust between Windows Server 2003 or Windows 2000 domains and Windows NT 4.0 domains so that users from either domain can be authenticated to access resources in the other domain.
Trusts between Windows 2000 or Windows Server 2003 domains and non-Windows Kerberos realms

Windows 2000 or Windows Server 2003 domains can be configured to trust non-Windows-brand operating system Kerberos realms, and non-Windows Kerberos realms can be configured to trust Windows Server 2003 domains by manually creating one-way or two-way realm trusts. Realm trusts can also be configured to be either nontransitive or transitive, depending on the level of interoperability you require with UNIX or Massachusetts Institute of Technology implementations of the Kerberos version 5 protocol.

When the direction of a one-way trust is from a non-Windows Kerberos realm to a Windows Server 2003 domain, the user in the Windows Server 2003 domain can access resources in the non-Windows Kerberos realm. When the direction of trust is from a Windows Server 2003 domain to a non-Windows Kerberos realm, users in the non-Windows Kerberos realm can access the resources in the Windows Server 2003 domain.
Top of page
Technologies Related to Trusts

Trusts depend on the NTLM and Kerberos authentication protocols and on Windows-based authorization and access control mechanisms to help provide a secured communications infrastructure across Active Directory domains and forests. The following diagram illustrates how authentication and authorization technologies relate to trusts and other components of the Windows distributed security model.

Trusts and the Windows Distributed Security Model

Applications and Net Logon

Both applications and the Net Logon service are components of the Windows distributed security channel model. Applications integrated with Windows Server 2003 and Active Directory use authentication protocols to communicate with the Net Logon service so that a secured path can be established over which authentication can occur.
Authentication Protocols

Active Directory domain controllers authenticate users and applications by using one of two protocols: either the Kerberos version 5 authentication protocol or the NTLM authentication protocol. When two Active Directory domains or forests are connected by a trust, authentication requests made using these protocols can be routed to provide access to resources in both forests.
NTLM

The NTLM protocol is the default protocol used for network authentication in the Windows NT 4.0 operating system. For compatibility reasons, it is used by Active Directory domains to process network authentication requests that come from earlier Windows-based clients and servers. Computers running Windows 2000, Windows XP or Windows Server 2003 use NTLM only when authenticating to servers running Windows NT 4.0 and when accessing resources in Windows NT 4.0 domains.

When the NTLM protocol is used between a client and a server, the server must contact a domain authentication service on a domain controller to verify the client credentials. The server authenticates the client by forwarding the client credentials to a domain controller in the client account domain. The authentication protocol of choice for Active Directory authentication requests, when there is a choice, is Kerberos version 5. When the Kerberos protocol is used, the server does not have to contact the domain controller. Instead, the client gets a ticket for a server by requesting one from a domain controller in the server account domain; the server validates the ticket without consulting any other authority.
Kerberos Version 5 Protocol

The Kerberos version 5 protocol is the default authentication protocol used by computers running Windows 2000, Windows XP Professional, or Windows Server 2003. This protocol is specified in RFC 1510 and is fully integrated with Active Directory, server message block (SMB), HTTP, and remote procedure call (RPC), as well as the client and server applications that use these protocols. In Active Directory domains, the Kerberos protocol is used to authenticate logons when any of the following conditions is true:•
The user who is logging on uses a security account in an Active Directory domain.

The computer that is being logged on to is a Windows 2000, Windows XP or Windows Server 2003–based computer.

The computer that is being logged on to is joined to an Active Directory domain.

The computer account and the user account are in the same forest.

The computer from which the user is trying to access resources is located in a non-Windows Kerberos realm.

If any computer involved in a transaction does not support the Kerberos version 5 protocol, the NTLM protocol is used.
Authorization and Access Control

Authorization and trust technologies work together to help provide a secured communications infrastructure across Active Directory domains or forests. Authorization determines what level of access a user has to resources in a domain. Trusts facilitate cross-domain authorization of users by providing a path for authenticating users in other domains so their requests to shared resources in those domains can be authorized.

Once an authentication request made to a resource in a trusting domain is validated by the trusted domain, it is passed to the targeted resource computer, which determines, based on its access control configuration, whether to authorize the specific request made by the user, service, or computer in the trusted domain. In this way, trusts provide the mechanism by which validated authentication requests are passed to a trusting domain, while access control mechanisms on the resource computer determine the final level of access granted to the requestor in the trusted domain.

Note•
“Access to resources” in any discussion of trust relationships always assumes the limitations of access control.

Two new and one updated advisory discussing PoC and exploits

Lennart Wistrand here. This week we’ve seen both proof of concept code posted for a Windows Shell vulnerability. We have also seen limited exploits of a previously publicly disclosed vulnerability in DirectAnimation as well as limited exploits of a PowerPoint vulnerability.
We’ve made the Windows Shell advisory available to advise customers of this public PoC. The advisory calls out mitigating factors and workarounds and does also touch upon our plans around releasing a security update that addresses this. The advisory can be found here.

We’ve also made a small update to the DirectAnimation advisory to call out that we have seen very limited attacks occur. That advisory can be found here.

Finally, we’ve published a PowerPoint advisory as well regarding limited attacks using specially crafted PowerPoint files.
In each case, user interaction is required for a successful exploit to occur and our Safe Browsing guidance applies. Reading e-mail using Outlook or Outlook Express can, in and of itself, not put you at risk but if you click on a link in an e-mail from an untrusted source you could be at risk. Keep your anti-virus software up to date and use caution when browsing. Please refer to the advisories for a more in-depth discussion of this.
We are working overtime to help get all of you more secure and we do continue to encourage security researchers to work with us towards resolutions to vulnerabilities that are discovered.
-Lennart
*This posting is provided "AS IS" with no warranties, and confers no rights.*
Article:


http://209.34.241.68/msrc/archive/2006/09/29/459967.aspx

Instant Messaging in the Workplace

Management and Security Considerations for Instant Messaging in the Workplace

Microsoft Corporation

Published: December 2005

Abstract

This paper identifies potential threats to corporate computer security that can result from the use of instant messaging in the workplace. It discusses specific risks and defines steps that organizations can take to ensure the security of their collaborative work environment.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© December 2005 Microsoft Corporation. All rights reserved.

Microsoft, Antigen, Windows, Windows Server System, and the Windows Server System logo are either registered trademarks or trademarks of Microsoft Corporation or Sybari Software, Inc. in the United States and/or other countries. Sybari Software, Inc. is a subsidiary of Microsoft Corporation.

All other trademarks are property of their respective owners.

Contents

Introduction

Business Benefits of Instant Messaging

Reduced Storage Space and Costs.

Risk Factors to Consider

Industry-Specific Challenges

Why IM Security is Critical

Worms

Backdoor Trojans

Hijacking and Impersonation

Phishing

Denial-of-Service Attacks

Information Disclosure

Undesirable Content

IM Management and Implementation

Evaluate Usage

Assess Potential Risk vs. Value

Decide Whether to Deploy an Enterprise IM Solution

Establish Consistent Corporate Policies

Educate Users

Protect IM and File Sharing from Virus Attacks

Centralize Control for Regulatory Compliance and Legal Protection

Tools for Secure Instant Messaging

Antigen for Instant Messaging

Layered Defenses

Content Control

Server Optimization

Conclusion

Related Links

Introduction

Over the past several years, instant messaging (IM) has evolved from a tool used almost exclusively by computer experts and systems administrators into an everyday communication mechanism for business users. Technology research firm the Radicati Group estimates that in 2004, 13.9 billion IM messages were sent per day, with an increasing number of these used for business collaboration.[1] Clearly, increasing numbers of businesses are realizing that real-time communications such as IM can help streamline communications and save considerable time and money.

As instant messaging technology is embraced by information workers and their organizations, it is important that system administrators and information technology (IT) professionals within these organizations recognize both the value and the potential risks posed by this new technology. Businesses must ensure that, like every other technology they have in place, IM is included both in IT plans and in corporate security and usage policies.

In particular, two attributes of instant messaging technology merit attention from IT professionals:

· Because the technology is relatively new but proliferating quickly, IM has increasingly become the target for attackers to propagate IM-borne viruses, worms, spam over IM (spim), malware, and phishing attacks.

· Because IM clients are widely (and often freely) available, they can be installed by end users without knowledge or involvement from the IT organization. This is especially true for organizations with mobile and remote employees. Thus, while widespread in adoption, IM is often unprotected and unmonitored in consumer and enterprise environments, leaving it vulnerable to attacks and exploits.

The following paper discusses the benefits and risk factors to consider when adopting IM in the workplace, as well as recommendations for implementing and managing IM to obtain these benefits without compromising the security of the computing environment.
Business Benefits of Instant Messaging

IM is a highly effective, expedient means of communication. Real-time text discussions harness information workers’ ability to multi-task and break through typical organizational barriers to increase productivity. For example, a user can be on the phone with a customer while using IM to gather necessary information from others in the organization to help solve a problem or close a sale.

Additional benefits include:

· Presence Awareness. The ability to initiate real-time communications with an associate or business partner is first enabled by knowing whether contacts are online, temporarily away from their desks, or on the road. Presence awareness allows users to indicate where they are and where/how/when is the best time to contact them.

· Reduced Long Distance Costs. Although IM is most commonly used for two-way conversations in a business capacity, most programs offer a conference or chat setting where workgroups can meet and conduct focused conversations. Using IM to interact with employees and clients across the globe in real time can reduce an organization’s long-distance phone charges.

· Reduced Storage Space and Costs. When personal messages are sent via e-mail, they are stored in the groupware solution and subsequently backed up. Storing and backing up these messages consumes valuable space, with little or no business value. Sending these messages via IM rather than e-mail frees up storage space for business-critical information.
Risk Factors to Consider

For some organizations, the use of public IM clients is an acceptable, low-cost alternative to traditional forms of communication. However, reliance on public or consumer-class IM applications creates some unique obstacles:

· The organization has little or no control over how IM applications are used and implemented. Public IM applications cannot be easily “locked” to constrain the types of messages sent or with whom they may be exchanged.

· The lack of interoperability between major IM applications makes standardization difficult. Users may have to install multiple IM clients to communicate with all of their intended parties.

· As both legitimate and unapproved use of instant messaging clients and peer-to-peer networking increases, new worms and viruses are increasingly using these mechanisms to spread. According to the IMlogic Threat Center, IM-based threats are increasing at an alarming rate.[2] Without specific security measures in place to protect against IM-based attacks, organizations may be exposing corporate networks to unacceptable levels of risk.

· IM interactions are not easily captured, logged, or audited. After the client software is closed, messages are typically deleted. Hence, these messages do not become part of any interaction history, and thus the information cannot be mined or used for customer relationship management (CRM) or compliance purposes.
Industry-Specific Challenges

In addition to these common challenges, business may face additional issues specific to their industry or line of business. Two examples of these industry-specific considerations are presented below. Ultimately, each organization must assess its unique needs to ensure that the instant messaging solution fits well with its unique security, communications, and compliance strategy.

· Scenario: Customer Service. Customer service organizations that rely on consumer-class IM for communications with customers may find that the inability to log or record IM conversations is a liability. While customers may appreciate the immediacy of the communication, the organization may suffer from the lack of integration with enterprise CRM or issue-tracking tools. Likewise, the lack of a permanent record may hamper accountability or efforts to follow up with customers.

· Scenario: Financial Services. Organizations with strict regulatory compliance burdens should be especially aware of issues relating to the use of IM clients. For example, financial service providers (FSPs) such as brokerage firms have a particular difficulty with public IM clients that do not provide the tools or capabilities required by the U.S. Securities and Exchange Commission (SEC) for monitoring and archiving written communications. Federal regulations stipulate that FSPs must take measures to document any form of financial advice or communication. It also requires FSPs to screen communications for any possible sharing of insider trading information. Because of these regulations, any FSP that relies on public IM applications must consider the potential legal implications.

In each of these scenarios, the risk and exposure posed by the non-secure, unmonitored communication provided by public IM clients could outweigh the benefits of real-time communication. To implement instant messaging effectively, and without compromising security, compliance, or communications policies, these organizations require solutions that provide centralized management and tracking of IM communications.
Why IM Security is Critical

Organizations invest a great deal of money in security and considerable time implementing corporate policies to prevent users from becoming carriers or transmission points for malicious code; inappropriately sharing confidential company information; or sending or receiving language or materials that exposes the corporation to legal liabilities. The conversation and file transfer capabilities of consumer-class or publicly available IM applications can make it easy for users to bypass traditional security measures and e-mail policies. This leaves systems susceptible to attacks such as worms and Trojan horses that export data and create “back doors” into the system. As IM increases in popularity, its utilization as a vector for potential malicious attacks or as a means for sending unsolicited information is expected to increase as well. For this reason, it is essential that enterprises put plans in place for this new collaboration application, protecting themselves from these threats.
Worms

Potentially devastating e-mail worms are a common reality for any computer security professional. These e-mail threats can be dealt with effectively by using antivirus products that monitor e-mail traffic. IM-specific worms are a newer threat, and their numbers are steadily rising.
Backdoor Trojans

Some malicious Trojan horse programs target IM by modifying configuration settings to enable file sharing for an individual’s entire hard drive, thus allowing hackers full file access to a machine. Meanwhile, classic backdoor Trojans utilize IM to send messages to the author of the Trojan horse, giving the hacker information about the infected computer.
Hijacking and Impersonation

There are several ways that hackers can impersonate unsuspecting users to access their account information. As noted, a hacker can obtain the account information of a user, including passwords, via a Trojan horse. He or she can then impersonate the victim and convince the victim’s “buddies” to run files on their computers or divulge additional confidential information. A hacker can also use a simple denial-of-service exploit or other unrelated exploits to make a client disconnect. Since the server keeps the connection open and does not know that the client has disconnected, the hacker can then impersonate the user. Furthermore, since all data is unencrypted and unauthenticated, a hacker can use classic man-in-the-middle attacks such as address resolution protocol (ARP) spoofing.
Phishing

“Phishing” is a form of attack in which an attacker attempts to fraudulently acquire sensitive information, such as passwords and credit card details, by sending e-mail or instant messages that appear to originate with a trusted source. Phishing schemes are becoming increasingly common and increasingly sophisticated, making it difficult for users to recognize and ignore or delete fraudulent messages.
Denial-of-Service Attacks

Hackers can cause denial-of-service attacks on IM clients in various ways. Some attacks cause the IM client to crash. Other types of attacks make the client “hang,” and in some cases consume a large amount of CPU power, causing an entire computer to become unstable. One common method of attack is to flood a particular user with a large number of messages. Although some IM clients protect against flood attacks by allowing users to ignore other users, certain tools allow the hacker to use multiple accounts simultaneously or automatically create a large number of accounts to accomplish the flood attack. Furthermore, once a flood attack has started, a computer may become unresponsive by the time the victim realizes what is happening. This makes it virtually impossible to add the attacking user accounts to the “ignore” list of the IM client in a timely manner.
Information Disclosure

Tools that attempt to retrieve system information from IM users, such as IP address retrievers, are frequently used by hackers. For instance, if an IP address retriever is used in conjunction with a backdoor Trojan horse, a hacker could receive a message containing the IP address of an infected user each time the victim is online. In this manner, a hacker could know the IP address of the infected user, even if he or she uses dynamic IP addresses.
Undesirable Content

Because IM applications can often be used to exchange files or other sensitive information easily and without trace, organizations must recognize it as a potential threat to confidentiality and legal liability. Examples include the ease with which users can pass confidential company information, use prohibited language (sexual harassment, profanity, etc.) as well as to share unauthorized file types. The use of corporate networks to share media files (e.g.,.mp3 and .avi files) has been the subject of recent litigation, while other file types (e.g., .exe and .vbs) can be used to harbor malicious code.
IM Management and Implementation

Before implementing IM in an enterprise environment, organizations should carefully consider the issues described below.
Evaluate Usage

Understanding existing deployments and usage patterns is the first step to gaining control over IM usage in the workplace. Because many IM client applications are preinstalled or can be downloaded for free, employees may have started using IM applications on their own, unbeknownst to administrators or security officers. Several programs are available that can audit usage and identify users that have IM clients deployed. These programs are essential to developing an accurate picture of which applications are in use (including version), by whom, and what they are being used for.
Assess Potential Risk vs. Value

Determine the value of implementing company-sanctioned IM usage throughout the organization. How will employees and the organization as a whole benefit from presence awareness, real-time communication, reduced e-mail usage, or reduced telephone costs? Should IM be deployed for internal use only, or will it be used to communicate with customers and partners, as well? Organizations must weigh the benefits of instant messaging against potential risks to security, compliance, and corporate image that might result from use or misuse of the technology.
Decide Whether to Deploy an Enterprise IM Solution

The decision should be based on the value to the organization and the ability to manage risk, as well as factors including network use, availability, and security standards. Enterprise IM solutions such as Microsoft® Office Live Communications Server 2005 provide organizations with a powerful internal IM system. Regardless of whether or not an enterprise IM solution is deployed, companies must decide whether and under what circumstances to allow the use of consumer IM clients on the organization’s desktops.
Establish Consistent Corporate Policies

Corporate IT policies should be expanded to address IM usage. Companies should examine their motives for managing IM at the corporate level, for example to ensure compliance with legal regulations, management of security issues such as viruses, communication storage, prevention of sensitive data theft, or avoidance of the risk of remote hacking. File and content-filtering policies can be used as the first line of defense against viruses that propagate via IM clients. Certain filters can be static, such as those that block scripts or executable files.
Educate Users

Administrators should educate their users on both the benefits and the risks of IM usage, including how to recognize phishing schemes, and the potential impacts if a client is hijacked. These guidelines should be communicated to all employees as part of an updated corporate messaging policy that covers both e-mail and IM usage.
Protect IM and File Sharing from Virus Attacks

Ensure that enterprise IM solutions and consumer managed solutions are secured from the aforementioned threats. For example, security experts recognize the limitations of relying on desktop antivirus protection alone for protecting e-mail servers, messaging gateways, and collaboration applications. Today, a prudent “defense in-depth” strategy relies on multiple levels of scanning and the use of multiple antivirus engines. Antivirus protection should be enabled so that IT administrators can manage and secure enterprise and public IM communications at the server level.

Even organizations that deploy enterprise IM solutions for internal use only should implement security measures to prevent the corporate messaging systems from being used to propagate malicious code or inappropriate content that is introduced through other sources.
Centralize Control for Regulatory Compliance and Legal Protection

When deploying IM to desktops, organizations should also deploy tools that enable administrators to log messages, scan for inappropriate content, and implement corporate messaging policies from a central server environment. Centralized protection mechanisms enable organizations to manage and control IM traffic.
Tools for Secure Instant Messaging

Secure, well managed instant messaging requires technology beyond the desktop messaging client. A central messaging server, such as Live Communications Server 2005, provides control and management functionality, while specialized security tools, such as Antigen® for Instant Messaging, deliver antivirus scanning, content filtering, and message content scanning. Together, these technologies create a secure, manageable, collaborative environment. Tight integration between Live Communications Server and Antigen for Instant Messaging enables organizations to apply corporate security policies consistently and to deploy IM solutions without compromising the security of the enterprise environment.
Antigen for Instant Messaging

Antigen for Instant Messaging is a server-based antivirus solution that provides comprehensive protection for Live Communications Server and its Office Communicator and Windows® Messenger clients. For organizations that allow use of public IM clients, Antigen for Instant Messaging also integrates with IMlogic IM Manager on a separate server to provide threat protection for other public IM clients. By using layered defenses, corporate content policy enforcement, and optimization of messaging server resources, Antigen for Instant Messaging provides comprehensive protection to ensure that messages and file transfers are secure at all times.
Layered Defenses

By managing multiple antivirus scan engines to scan all IM and file transfers, Antigen for Instant Messaging minimizes the average window of exposure for emerging threats by providing and managing frequent signature updates from multiple antivirus labs around the world. Layered defenses also protect against downtime; if one engine fails or goes offline to update, other engines remain active to provide protection, ensuring that IM service is not interrupted and user security and compliance are not compromised.
Content Control

Through administrator-defined content filtering rules, Antigen for Instant Messaging helps enforce compliance with corporate policy for language usage and confidentiality within IM conversations and file transfers. Customizable filters help protect against inadvertent or intentional transmittal of inappropriate content, such as offensive language, legally or ethically questionable material, or confidential company information. Antigen for Instant Messaging includes a set of predefined, customizable keyword dictionaries to target profanity, discriminating language, and spim. Administrators also have the ability to configure file filtering rules that block file types that may contain malicious content (for example, .exe) or expose organizations to legal liability (for example, .mp3).
Server Optimization

Antigen for Instant Messaging integrates closely with Live Communications Server, optimizing server performance and ensuring that protection does not overtax server resources. With features like in-memory scanning, multi-threaded scanning processes, and performance bias settings, businesses can achieve the benefits of multiple-engine scanning without introducing additional processing time or server performance degradation.
Conclusion

IM is rapidly becoming a staple in corporate communications, enabling employees to share information and documents in real-time. However, as IM introduces new collaboration capabilities and productivity gains, it also has the potential to introduce new threats to corporate computer security. Because of growing IM use, organizations need to address the security concerns associated with IM-specific malicious code as well as undesirable content.

By leveraging best practices and the appropriate technology solutions, today’s organizations can create an enterprise IM system that adds significant business value while enabling consistent policies and threat protection across their networks. Enterprise-class collaboration tools such as Microsoft Office Live Communications Server and Antigen for Instant Messaging provide a high degree of management and security, enabling organizations to adopt these new collaborative technologies with confidence.

Related Links

See the following resources for further information:

· For in-depth information on computer security, including the latest updates, best practices, and tips for IT professionals and businesses, visit www.microsoft.com/security

· For information on enterprise IM solutions built on Microsoft Office Live Communications Server, visit www.microsoft.com/lcs

· For more information on Antigen for Instant Messaging, visit www.microsoft.com/sybari

For the latest information about Microsoft Windows Server System™, see the Windows Server System Web site at http://www.microsoft.com/windowsserversystem.

[1] Radicati, Instant Messaging Market, 2005-2009, July 2005.

[2] According to a security threat report published by IMlogic, IM and P2P threats increased 3295% in Q3, 2005 over Q3, 2004 bringing the year-to-date increase to 2083%. Growth from Q1 to Q3, 2005 was also significant with reported threats increasing by almost 32% quarter over quarter.

DNS Best Practice

The original article can be found here

Bill: We are planning on building a root domain from scratch at our HQ called "root.com" and then having separate child domains for Europe and North America. Can you provide some "best practice" steps and information on configuring DNS prior to installing AD for an environment such as this? I'd be very appreciative.

On a side note, our new 2003 AD structure will eventually include Exchange Server, but it will not start out that way. Will it cause any problems if we go ahead and extend the schema for the forest and domain ahead of time? If extending the schema will not be a problem, is it best to do it before or after the service packs are applied to the OS?
—Steve

Steve: It's a great idea to get your DNS infrastructure configured and tested prior to deploying Active Directory. Nearly all AD problems have a root cause in DNS.

In your example, you specified a DNS domain name of Root.com. I'm assuming that you're actually going to use another name that you've registered to assure uniqueness. I'll use root.com in all the examples.

Start with a Standalone DNS Server
Start by installing a standalone DNS server running Windows Server 2003. You'll eventually integrate DNS into Active Directory and use the domain controllers as DNS servers, but installing a separate DNS server at first gives you more control over the process in case something goes wrong.

You don't need server-class hardware for this machine. You'll only be using it temporarily. I often use a virtual machine (using either VMware or Microsoft Virtual Server) to act as the initial DNS server in a new forest.

Before you install DNS on the server, change the Server Properties to include a DNS suffix. Access the Server Properties window by holding down the Window key and tapping the Pause key. Select the Computer Name tab then click Change then click More.

Assign a DNS suffix of Root.com to the server. This creates a Registry entry called NVDomain that Windows concatenates to the host name (NVHost) to get a Fully Qualified DNS Name (FQDN), such as RootDC.Root.com.

Important: A Windows DNS server will not accept dynamic updates unless it has an FQDN, which means you must make the NVDomain entry on the standalone server.

You'll be required to restart the server after making the NVDomain entry.

Install DNS on the Standalone Server
Following the restart, install the DNS service on the server. Create a new zone called Root.com. Configure the zone to accept dynamic updates. You can't use secure updates until you have integrated DNS into Active Directory, so don't point any clients at this DNS server.

You can create a reverse lookup zone, if you like, but that isn't absolutely required at this point.

By default, the DNS service will be able to resolve out-of-zone queries (such as queries for Internet hosts) using Root Hints. You may prefer to configure the server to use a forwarder.

Configure DNS Settings at the Domain Controller
You’re now ready to install the first domain controller in the root domain. Install the operating system and configure the TCP/IP settings to use the standalone DNS server for DNS lookups. Don't make any changes in the DNS tab of the TCP/IP settings or to the DNS suffix in System Properties. DCPromo will automatically configure these settings based on the domain name you supply during the promotion.

To make sure that the DNS settings are correct, run DCDiag with the following syntax:

dcdiag /test:dcpromo /dnsdomain:root.com /newforest

You should get the following response:

Starting test: DCPromo
Messages logged below this line indicate whether this domain controller will be able to dynamically register DNS records required for the location of this DC by other devices on the network. If any discontinuationDcPromo is detected, it might prevent dynamic DNS registration of some records, but does not prevent successful completion of the Active Directory Installation Wizard. However, we recommend fixing the reported problems now, unless you plan to manually update the DNS database. DNS configuration is sufficient to allow this domain controller to dynamically register the domain controller Locator records in DNS. The DNS configuration is sufficient to allow this computer to dynamically register the A record corresponding to its DNS name.

......................... RootDC passed test DcPromo

If you get a failure, the error message will give you a hint as to the cause. The most common causes are typos in the DNS IP address or in the DCDiag strings.

Run DCPromo and create the new forest. During DCPromo, you will get a DNS Registration Diagnostics window that hopefully contains no errors. Here's an example:

Diagnostic Results
The registration diagnostic has been run 1 times.
DNS registration support for this domain controller has been verified. To continue, click Next.

Details
The primary DNS server tested was: DNS1.Root.com (10.10.0.1)
The zone was: Root.com
The test for dynamic DNS update support returned:
"The operation completed successfully."

If the window says you have an error, you can continue with the promotion then troubleshoot later. That's the advantage of having a separate DNS server.

Following the restart of the domain controller, check the DNS zone to ensure that it contains a set of SRV records for the root.com zone. If these records do not appear, run netdiag /fix at the newly promoted domain controller. This takes the SRV records from a flat file called NeDNSgon.dns and uses them to perform the DNS dynamic registration. If the SRV records still do not appear, check the Event Log for errors.

Change Default Site Name
Assuming that everything looks good at this point, use Active Directory Sites and Services to change the name of the first site from Default-First-Site-Name to the name of your headquarters site. Let's call it HQ. Verify that this change is reflected in DNS. Drill down through the SRV records and make sure that the site name now reads HQ in any place it appears. If this does not happen, refresh the display then run netdiag /fix at the domain controller.

Initial Exchange 2003 Configuration
Since you're going to be running Exchange 2003, now would be a good time to run Forestprep and Domainprep for Exchange. This will make the required Schema changes, install a placeholder Exchange organization in the Configuration naming context, and create the necessary Exchange groups in the root domain of the forest. By doing this work now, all the forest changes will automatically get replicated to any new domain controllers you install.

Create DNS Child Domains
You're now ready to create DNS zones for the child domains (let's call them NA.Root.com and EU.Root.com) and install domain controllers for these domains. I'm assuming that you're going to want a server from each child domain in the company headquarters, so you don't need to create additional sites at this time.

Create the zones for the child domains on the same DNS server where you created the root zone. Eventually you'll integrate these zones into Active Directory. Be sure to enable dynamic updates on these zones.

Note: You don't have to create separate zones. The dynamic update process will create child DNS domains in the root zone file. But I like keeping the resource records in their own zones because it makes the transition to Active Directory a little easier to follow.

So, you now have three zones on the standalone DNS server. Install a domain controller in the two child domains using the same steps that I outlined for the root domain. Configure the TCP/IP settings oDC'soth DCs to point at the standalone DNS server as their sole DNS server. Use DCDiag to confirm that the zone information is correct. The DCDiag syntax for the child domains would be:

dcdiag /test:dcpromo /dnsdomain:NA.Root.com /childdomain

Following the restart after DCPromo, be absolutely sure that all SRV records are present in each zone. The critical records, at least from the perspective of Active Directory replication, are the CNAME records in the _msdcs.root.com zone. The replication agent on each domain controller queries DNS for this record based on the Globally Unique Identifier (GUID) of its replication partner. The GUID information is stored in Active Directory.

Wait 15 to 30 minutes for the KCC on eachDC's DC to grok (that is, to fully understand) the new topology and to create the necessary connection objects between the DCs. Then use Active Directory Sites and Services to force replication between the three domain controllers. If you get a "Naming Context in the process of being moved..." error, then wait a while longer for the KCC to do its thing. If you get an "RPC Server not found..." error, then you have a DNS configuration problem.

Additional Exchange 2003 Configuration
Exchange requires you to run Exchange Domainprep in every domain that hosts Exchange servers. Take a few minutes right here to run Domainprep in the two child domains.

AD-Integrate the DNS Zones
Okay, with everything working fine up to this point, you're ready to integrate the zones into Active Directory. Once a zone file has been integrated into Active Directory, any domain controller running DNS automatically becomes a primary master for that zone.

It's essential to integrate DNS into Active Directory if you're going to use dynamic updates. If you configure your DNS servers to accept dynamic update requests from unvalidated sources, it's just a matter of time before someone inadvertently or purposefully poisons your zone file with invalid resource records.

Windows only accepts one form of secure dynamic updates, a proprietary method that relies on the underlying object-based security in Active Directory. For this reason, secure updates require that you integrate the zone records into Active Directory.

Here's where DNS can get a little complicated. Under most circumstances, you don't want to replicate resource records for the NA.Root.com zone to the domain controllers in Europe, and vice versa. Windows Server 2003 has a feature where you can place DNS records in separate naming contexts then target replication for those naming contexts.

In LDAP, a naming context forms a replication boundary. It's often called a "partition" although that's not formally correct as perRFC's LDAP RFCs.

Resource records for a domain are placed in a naming context called DomainDNSZones under the same domain. For example, resource records for the NA.Root.com zone would be placed in a naming context with the following Distinguished Name:

DC=DomainDNSZones,DC=NA,DC=Root,DC=com

Resource records intended for replication throughout the forest are placed in a naming conteDC'sDC'sxt called ForestDNSZones under the root domain namespace as follows:

DC=ForestDNSZones,DC=Root,DC=com

Create the DNS Naming Contexts
When you install DNS on the Infrastructure Master in each domain, it will automatically create the DomainDNSZones naming context in its domain. When you install DNS on the Infrastructure Master in the forest root domain, it will also create the ForestDNSZones naming context.

Also, Windows Server 2003 allows you to target replication of these naming contexts to Active Directory domain controllers that are actually running the DNS service. After all, why waste time replicating DNS resource records to a domain controller that can't reply to DNS queries?

The next step, then, is to install DNS on the three domain controllers. Since each of these DCs is also the Infrastructure Master for its domain, this will result in the creation of the special DNS naming contexts.

Since you now have multiple DNS servers, it makes sense to use a forwarder to handle Internet host lookups. Most organizations either contract with their ISP to use a DNS server at the ISP or they put a caching-only DNS server in their DMZ.

Starting with the domain controller in Root.com, change the TCP/IP settings on each DC to point the server at itself for DNS lookups. In other words, the IP address in the Primary DNS setting should match the IP address of the server. (Don't do this in a Windows 2000 forest root domain. There's a flaw in the way Windows 2000 obtains the CNAME records for domain controllers and this flaw can cause replication failures if you point a root DC at itself for DNS. This flaw is fixed in Windows Server 2003.)

Now, install the DNS service on each of the DCs. On the root DC, create a zone for the Root.com domain. Configure the zone as Active Directory integrated and set the security to accept only secure updates. In the Active Directory Zone Replication Scope window, select the radio button labeled "To All DNS Servers in the Active Directory domain root.com."

On the other two domain controllers, configure a zone for each server's domain: NA.Root.com and EU.Root.com. Configure the zones as Active Directory integrated with secure updates only. Select the option to replicate the zone only to DNS servers in the respective domain. Populate the zones with resource records by running netdiag /fix at each DC. Verify that the SRV records appear in the three zones.

One more zone to go. At the root DC, create a new Forward Lookup Zone called _msdcs.root.com. Make this an Active Directory integrated zone and configure the scope option to replicate to every DNS server in the forest. When you do this, the zone will automatically populate with SRV records and a dimmed folder will be left behind in the root.com zone. This zone contains the records required to support forest-wide replication, so that's why you want a copy of it on every domain controller. The number of records is small, so the intercontinental replication load is trivial.

Configure Stub Zones
At this point, the domain controllers face a dilemma. They point at themselves for DNS lookups and there are no resource records in their copy of Active Directory to tell them where to find domain controllers in the other domains. This will cause replication failures.

The classic DNS way to handle this situation would be to configure the child domain controllers to forward their out-of-zone lookups to the DNS server in the root domain and to create delegation records in the root domain that point at the name servers in the child domains.

However, it's simpler to use another new Windows Server 2003 feature called "stub zones."

A stub zone is a special copy of a zone that contains only the Name Server (NS) records and their associated A (Host) records, often called glue records. If the DNS server receives a query for a host in the stub zone, it refers to the NS records in the stub zone to find the DNS servers in that domain. It then uses the IP addresses in the glue records to send the query to one of the DNS servers in the target zone. When it gets a resource record as a reply, it returns a copy of the record to the client who originated the query.

Stub zones do not require special replication permissions. The zone only contains NS and glue records, which are freely available via a standard DNS query. To repeat, stub zones do not require zone transfers.

Stub zones, then, take the place of traditional DNS delegation. They are especially handy in a Windows Server 2003 forest because you can integrate the stub zone into Active Directory so that every DNS server in a domain can find the NS and glue records.

The final step, then, is to create an Active Directory integrated stub zone in each domain representing the other domains. For example, the Root.com domain would need stub zones for NA.Root.com and EU.Root.com, while the NA.Root.com would need stub zones for Root.com and EU.Root.com.

With the stub zones in place, you should be able to get error-free replication between the domain controllers. You can now join a few clients to the domains and make sure that they can authenticate and get access to resources in the other domains and resolve Internet host addresses.

Go Forth and Configure DNS
Configuring DNS in a multiple-domain forest can get fairly complex, but this quick checklist should help you anticipate most of the problems.

Google