Multi-Site Single domain setup

Hello,

I know this question or very similar questions have been asked before, and I have gleaned some tidbits by searching the archives, however I have not located a concise answer.

We are running AD integrated DNS. I would like a setup such that I have a DNS entry such that when a user logs in from a given geographical site, they get directed to their local Wildfire server. They can then communicate with any other users via addresses such as user@im.company.com or user@company.com. Which server they are talking to would be seamlessly invisible, letting them communicate with any user globally.

I have read over the docs in other threads and the jive document on SRV records, but the answers are not clear.

Is anyone doing this? What entries need to be in AD, and how are they entered? What is your domain set to on wildfire? Are you keying off the user’'s subnet or their AD authentication server.

I’'m looking for new answers here, pointers to previous threads have already been read.

Thanks.

Chrisla

Can you give us a bit more specific scenario about how you actually want to set up?

Do you mean that you company have multiple site in different area, thus

you have 3 users from 3 location and you want them to talk to each other?

user1@areaA.company.com

user2@areaB.company.com

user3@areaC.company.com

If areaA, areaB and areaC are all in the internal network, you can just set up a single server wildfire.company.com and they all can talk to each other.

if you want to set up server for each area, you still can do wildfireA.company.com, wildfireB.company.com and wildfireC.company.com , then you can use s2s (server to server) option to make them talk each other.

if you want to have server in each area but you only want them to use wildfire.company.com , please vote for JM-191 .

Please let me know if I answer you.

Regards,

wmhtet

If areaA, areaB and areaC are all in the internal network, you can just set up a single server wildfire.company.com and they all can talk to each other.

This would work, but I would like to prevent the following:

  • If the Site to Site Intranet (yes they are all on the same internal WAN connected network) is down only users at HQ would be able to use the IM server. With distributed servers local communication could still take place.

  • I’‘d like to reduce site to site WAN traffic, so intra-office IM’'s stay in their respective LANs.

if you want to set up server for each area, you still can do wildfireA.company.com,

wildfireB.company.com and wildfireC.company.com , then you can use s2s (server to

server) option to make them talk each other.

I’'ve done this but it creates some Jabber login name distribution problems:

I am using the LDAP connectivity to pull in the account names, and groups from AD. Thus on each respective server I have:

user1@areaX.company.com

The users need to know that user1 logs into areaA.company.com, and user2 logs into areaB.company.com rather than a flat namespace. They need to add user1@areaA.company.com to their roster, in an AD scenario, this is even more confusing b/c user1@areaB.company.com also exists, but would never be logged into.

This unto itself is not the end of the world, as it is not such a big mega-corp that people don’'t know where each other work geographically. It does create confusion for any traveling salespeople however.

It does create a problem when shared rosters based on groups from AD come into the picture though. Each respective areaX server will pull in the same list of users from AD, except it will present them all as userX@areaLOCAL.company.com. So I have a shared roster saying Bob, Joe, and Sandy are all local, however in reality maybe only Bob and Joe would log into their local servers, and Sandy works at another site.

if you want to have server in each area but you only want them to use wildfire.company.com , please vote for New Feature-- Open: Unresolved JM-191

That sort of seems to relate more to High Availability failover, but maybe the problems are the same. I thought it was my understanding that this problem could be solved with clever DNS/SRV entries. I’'m looking for the advantages of a distributed server architecture, without loosing the advantages of a flat namespace.

Hope that clarified it.

Thanks!

chrisla

I also have the perception that s2s might be confusing for users and you have described the problem well. I don’‘t know that it can be solved with “clever DNS/SRV entries” as I don’'t know much about DNS. I would be more interested in it also. If you have some vague idea please post it here. Even though it might be a vague idea, other people can compliment it to get to the solution.

Regards,

wmhtet

I don’‘t know that it can be solved with “clever DNS/SRV entries” as I don’'t know much about > DNS.

If I were using BIND for a DNS server, the “view” functionality could be used. This allows the server to give it different answers based on the IP or IP range that is asking, such that:

If 10.0.0.12 asks what the IP for im.company.com is, it would get 10.0.0.50

If 172.32.0.12 asks what the IP for im.company.com is, it would get 172.32.0.50

In AD (I believe; I’‘m a NIX admin) it can do the same based on the Authentication Server of the client. I’'m nearly certain it can do the same or weight an SRV entry.

chrisla

Even if you can set up the wildfire server, there are issue with the authentication and database. For authentication, I think that it is not a big deal because for example in the AD enviroment, one might have domain controller in each site and one can always use that. However when it comes to database, I don’'t think that we can use database for each site and expect them to work together seeminglessly because if one has a manual group creation set up, the info resides on the database. So we need a cluster database with a clever DNS/SRV set up to have a multiple-site Single domain setup. Please enlighten me if my thinking is not correct.

Regards,

wmhtet

This is actaully not a big deal if using AD/DNS because you can setup “sites” in AD which provide, in this case the closet (same subnet) dns record that you are looking for if more then one exists.

ie:

A records

co.local 192.168.100.1

co.local 192.168.200.1

client in subnet 192.168.200.0/32 requests the record for co.local and they would get 192.168.200.1 because the sites in ad say it is the closet.

Same goes for SRV records