Friday, September 28, 2007

Enterprise Exchange Dedicated GC Design



Enterprise design Exchange is always one of the most stunning skills for every Exchange administrator/Engineer would love to involve one day. GC's (Global Catalog) servers are being used to locate mail enabled object within the SMTP domain by Exchange servers. The performance of Exchange Server will directly impacted if the GC The exchange Server is talking too is not fast enough to make the queries back to the Exchange server. In large enterprise environment Exchange administrators may wish to locks down DS (directory Access) for GC's by disabling the Automatic Discovery and hard coding the GC servers. This always been a good idea for large environments in my opinion.

Would it be better if we could dedicate GC for corporate Exchange servers.When I say dedicate I mean DC/GC will serve to Exchange server only and wont involve into any other services as regular DC does.. As we all know the DC (domain Controller) is authentication server, so it will authenticate users. Now we have problem here we want to dedicate the DC/GC for Exchange, how are we going to achieve this goal.

Special thanks to Joe Nagy for passing us his high level approach in scenarios related to Active directory and Exchange design, best performance and practices.

Solution:

First thing we will do is, creating OU called CG in the ADUC. We will Drag and drop the DC/GC into this organizational unit. Go to properties of OU, and

  • Click on group Policy
  • Click New
  • Name the Policy "DNS GC SRV Record Lift" click edit
  • Expend computer configuration
  • Administrative templates
  • System
  • Net logon
  • DC Locator DNs Records and on the right pane locate
  • Priority Set in the DC Locator DNS SRV Records
  • Set is anything over "33" because The SRV resource record has DNS type code 33,
  • Save it and Exit

Conclusion:

Dedication GC in large environment will improve the performance of Exchange, this is fact and this type of design should be considered as high level engineering approach.

Format of the SRV Resource Record:

The SRV resource record has DNS type code 33, with the following syntax: Service.Proto.Name TTL Class SRV Priority Weight Port Target

Service:

The symbolic name of the requested service, as defined in Assigned Numbers or locally. Some widely used services (notably POP) do not have a single universal name. If Assigned Numbers names the service indicated, that name is the only name that is legal for SRV lookups. Only locally defined services can be named locally. Service is case insensitive.

Proto:

TCP and UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally can be used (as for Service). Proto is case insensitive.

Name:

The domain this resource record refers to. The SRV resource record is unique in that the name searched for is not this name.

  • TTL: Standard DNS meaning.
  • Class: Standard DNS meaning.

Priority:

As for MX, the priority of this target host. A client must attempt to contact the target host with the lowest-numbered priority it can reach; target hosts with the same priority should be tried in pseudorandom order. The range is 0-65535.

Weight:

a load-balancing mechanism. When selecting a target host among those that have the same priority, the chance of trying this one first should be proportional to its weight. The range is 1-65535. Domain administrators should use Weight 0 when there is not any load balancing to do (to make the resource record easier for humans to read).

Port:

The port on this target host of this service. The range is 0-65535. This is often as specified in Assigned Numbers but need not be.

Target:

As for MX, the domain name of the target host. There must be one or more "A" records for this name. Implementers should, but are not required, to return the "A" record(s) in the Additional Data section. Name compression is to be used for this field. A Target of "." means that the service is not available at this domain.

http://support.microsoft.com/kb/232025

Best Regards

Oz Ozugurlu

No comments: