Tuesday, 19 May 2009

Using the ADAM Sites Tool with ISA Server 2006 Enterprise Edition

After doing a little research for one of my previous articles, it became apparent that there was very little guidance on the use of the ADAM Sites Tool apart from the default Word document that is included within the AdamSitesPack.exe archive that is available from here.

Based upon the concepts involved, I think that a working example is probably the best way to provide an overview of the necessary steps involved. This will allow people to move away from the default single site topology used by ADAM when using ISA Server Enterprise Edition, and explore the potential for a more suitable multi-site topology.

Although there is nothing actually wrong with the default single site topology used by Enterprise Edition, it does assume that all Configuration Storage Servers are ‘well connected’. Consequently, it does not factor in network bandwidth, network connectivity or any geographical boundaries that may exist. Therefore, this ‘well connected’ model is not necessarily the most optimum solution, and can be potentially improved upon in many cases.

Using the example environment covered from my previous blog entry titled ISA Server 2006/2004 Configuration Storage Server Frequently Asked Questions we have the following:

image4

Key features of this Configuration Storage Server design include:

  • A single, global ISA enterprise is used across all locations. This enterprise contains three arrays; one for each data centre location.
  • Dedicated Configuration Storage servers are used in each data centre location.
  • Configuration Storage servers are located local to the array members themselves.
  • Alternate Configuration Storage servers are located at each data centre to provide fault tolerance in the event of primary Configuration Storage server failure.

So, assuming we have varying degrees of connectivity between the data centres, it may actually be more beneficial to configure each location as a dedicated ADAM site.

With separate sites, it is then possible to configure inter-site replication with appropriate costs and replication intervals to better control replication traffic. The aim of the new design is to reduce unnecessary replication and also minimise bandwidth usage for ISA enterprise replication traffic.

So, who do we go about achieving this then? Well, we need to perform four main tasks:

  • Create ADAM Sites
  • Create ADAM Site Links
  • Move Configuration Storage Servers
  • Replicate Configuration Changes

Create ADAM Sites

Firstly, we need to define the new sites. Generically this can be achieved using the following command:

adamsites site create <Site Name>

Please Note: For the purposes of this article, all commands are being entered on the same Configuration Storage Server, namely LONCSS1.

In our example, this would therefore be achieved using the following commands:

adamsites site create London

adamsites site create Miami           

adamsites site create Singapore

We can verify all sites have been created correctly using the following command:

adamsites sites

This command should produce the following text output:

Site: Default-First-Site-Name
There are six servers in this site.
    LONCSS1
    LONCSS2
    MIACSS1
    MIACSS2
    SINCSS1
    SINCSS2
Site: London
There are no servers in this site. 
Site: Miami
There are no servers in this site.
Site: Singapore
There are no servers in this site.

Create ADAM Site Links

Next, we then need to create the site links that connect sites together, along with defining suitable replication costs and replication interval values that are representative of our example environment. By connecting sites, Configuration Storage Servers at each site will be able to replicate ISA enterprise changes with each other.

Site links can be created using the following command:

adamsites sitelink create <Sitelink Name> <Count> <Site1> <Site 2> <Site N> <Replication Cost> <Replication Interval>

If we return to our example environment and consider the network topology shown below:

image

This diagram shows the network topology in terms of link speed and connectivity, and provides the key information needed for defining the correct site links and properties.

In order to calculate the replication cost, we can use the following formula referenced for Active Directory site link costs:

 

Replication cost = 1024 x 1/logbandwidth (in Kbps)

 

Using this formula and the figures shown in the above diagram, we can therefore derive the following cost values for each site link:

Site Link

Cost

London-Miami

255

London-Singapore

340

Miami-Singapore

378

If we then think about replication intervals; assuming we are happy to provide replication at least four times a day, we can set the replication interval to every six hours, or 360 minutes.

Based upon these values, we can therefore use the following commands to create the necessary site link objects:

adamsites sitelink create London-Miami 2 London Miami 255 360

adamsites sitelink create London-Singapore 2 London Singapore 340 360

adamsites sitelink create Miami-Singapore 2 Miami Singapore 378 360

We can verify all site links have been created correctly using the following command:

adamsites sitelinks

This command should produce the following text output:

Site Link: DEFAULTIPSITELINK
        Cost:100
        Replication Interval:180
        Description:CN=DEFAULTIPSITELINK
        Sites:
                Default-First-Site-Name
Site Link: London-Miami
        Cost: 255
        Replication Interval:360
        Description:CN=London-Miami
        Sites:
                Miami
                London
Site Link: London-Singapore
        Cost: 340
        Replication Interval:360
        Description:CN=London-Singapore
        Sites:
                Singapore
                London
Site Link: Miami-Singapore
        Cost: 378
        Replication Interval:360
        Description:CN=Miami-Singapore
        Sites:
                Singapore
                Miami

Move Configuration Storage Servers

With the necessary sites and site links created, the next step is to move the Configuration Storage Servers from the Default-First-Site-Name site to their respective new site locations.

Configuration Storage Servers can be moved using the following command:

adamsites moveserver <Configuration Storage Server Name> <Old Site> <New Site>

Therefore, for our example environment this is achieved using the following commands:

adamsites moveserver LONCSS1 Default-First-Site-Name London

adamsites moveserver LONCSS2 Default-First-Site-Name London

adamsites moveserver MIACSS1 Default-First-Site-Name Miami

adamsites moveserver MIACSS2 Default-First-Site-Name Miami

adamsites moveserver SINCSS1 Default-First-Site-Name Singapore

adamsites moveserver SINCSS2 Default-First-Site-Name Singapore

We can verify all Configuration Storage Servers have been moved correctly using the following command:

adamsites sites

This command should produce the following text output:

Site: London
There are two servers in this site.
    LONCSS1
    LONCSS2
Site: Miami
There are two servers in this site.
    MIACSS1
    MIACSS2
Site: Singapore
There are two servers in this site.
    SINCSS1
    SINCSS2

Replicate Configuration Changes

Finally, it is necessary to replicate the configuration changes to all other Configuration Storage servers throughout the enterprise. Unfortunately, the ADAM Sites tool will not perform this replication task for you and requires the use of the repadmin utility.

Please Note: It is important to use the repadmin.exe utility that is located in the %WINDIR%\ADAM\ directory. It is therefore recommended to change the current directory to this directory prior to executing the above commands.

Generically this can be achieved using the following commands:

For intra-site replication:

repadmin /syncall <Configuration Storage Server Name>:<Configuration Storage Server Port Number>

For inter-site replication:

repadmin /replicate <Source Configuration Storage Server Name>:<Configuration Storage Server Port Number> <Destination Configuration Storage Server Name>:<Configuration Storage Server Port Number> CN=Configuration,CN=<GUID>

Assuming that the ADAM Sites Tool commands defined above have been entered on the LONCSS1 Configuration Storage Server, intra-site replication can be initiated using the following command:

repadmin /syncall LONCSS1:2171

The repadmin /syncall command should result in the following text output: 

CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.

However, in order to cater for inter-site replication, we need use a slightly more complicated command which contains a globally unique identifier (GUID) which is unique to each ISA Server Enterprise deployment and forms part of something called the Naming Context. In order to obtain this GUID for your own environment, the following generic command can be used:

repadmin /showrepl <Configuration Storage Server Name>:<Configuration Storage Server Port Number>

Using LONCSS1 as an example, this will result in the following text output:

==== INBOUND NEIGHBORS ======================================

CN=Configuration,CN={GUID}
    London\LONCSS1$ISASTGCTRL via RPC

The placeholder define above as {GUID} will actually be a hexadecimal value similar to this: 999BC56F-C65E-4472-9EDE-215BD5515B61.

With this GUID known, we can now use the following command to initiate an inter-site replication from London to Miami:

repadmin /replicate loncss1:2171 miacss1:2171 CN=Configuration,CN={999BC56F-C65E-4472-9EDE-215BD5515B61}

and for inter-site replication from London to Singapore:

repadmin /replicate loncss1:2171 sincss1:2171 CN=Configuration,CN={999BC56F-C65E-4472-9EDE-215BD5515B61}

Each repadmin /replicate command should result in the following text output: 

Sync from <Source Configuration Storage Server Name>:2171 to <Destination Configuration Storage Server Name>:2171 completed successfully.

UPDATE: Many thanks to Pepito for providing clarification on the use of repadmin for ADAM inter-site replication.

With the inter-site replication completed, the final step is to initiate intra-site replication for Miami and Singapore to update the remaining Configuration Storage Servers. This can be achieved using the following commands:

repadmin /syncall MIACSS1:2171

repadmin /syncall SINCSS1:2171

Each repadmin /syncall command should result in the following text output: 

CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.

With all the above commands completed successfully, we have now replicated changes to all six Configuration Storage Servers, in all three sites.

So, we now have a custom site link design which properly supports the network characteristics of the example environment and provides a more optimum ISA Server enterprise replication model. This new replication model now includes the use of of both intra-site and inter-site relationships, in addition to the use of customised costs and replication intervals that match the exact needs (and constraints) of the example environment.

I hope this working example proves useful for those looking at deploying ISA Server Enterprise Edition where the default single site model is not the preferred, or most optimum, solution.

5 comments:

  1. I have my 5 cent to add to this very useful piece of information and is that the command
    repadmin /syncall css-server-name:2171
    only syncronize the CSS with others CSS in the same site, you must use the following command to syncronize across sites:
    repadmin /replicate css-server-name1:2171 css-server-name2:2171 partition-to-replicate
    where css-server-name1 and css-server-name2 has to be bridge server in different sites and the partition to replicate must be one of the three that the CSS have in use:
    * CN=Configuration,CN={6C73A1AE-D7DF-4947-919B-BE4177A04E2A}
    * CN=Schema,CN=Configuration,CN={6C73A1AE-D7DF-4947-919B-BE4177A04E2A}
    * CN=FPC2

    ReplyDelete
  2. >> Pepito

    Thanks very much for the clarification. I have now updated the article to include the difference between forcing intra-site and inter-site replication.

    Hopefully the revised version is now accurate.

    Cheers

    JJ

    ReplyDelete
  3. Replicating the command will configure the rest of the storage servers.

    ReplyDelete
  4. Can you use this same methodology with TMG?

    ReplyDelete
  5. Yep, but not actually tried it - CSS and EMS are pretty similar - please post back with results! :)

    ReplyDelete