Is it possible to replicate two servers with the same name?

HCL Domino Domino Forum
1

We have three existing domino servers. Server-1, Server-2 and Server-3

We need to duplicate these servers with the exact same Domino server names in the DMZ to allow web access to them while internal servers service the clients.

They must be called the exact same Domino names because of hard coded server names in the applications. Its possible apps will fail if we change the names of the servers.

The existing internal servers must be able to replicate with the three new servers in the DMZ. Server-1 internal to Server-1 DMZ and so on.

The domain must be the same because its also hard coded along with the server name. I need each set of servers to both have the same domain name and exist isolated of each other as if they other does not exist.

How can I get the three internal servers to cluster/replicate with the three servers in the DMZ

2

Subject: Don’t think that can be done…

I am not an admin, just a developer, but I don’t think you can have two servers with the same name.

Instead you should fix the applications. Now you know why you should not hard code server names in your applications…

What I usually do is to have a configuration document (a profile document) where I specify server names and other settings. Things like groups/users to get mail notifications when certain things happens, etc.

I then load those values when needed.

In my code I try to avoid any reference to specific servers. For example, I have Database A, where the users work, and database B, where certain documents are being stored (to avoid making database A too large).

I would use code like this:

Set thisdb = session.CurrentDatabase

Set otherdb = New NotesDatabase(thisdb.Server, settings.GetValue(“DatabaseB”))

‘settings’ is a class where I can get values from the global settings document, using the GetValues() method. Very convenient.

What you could do is toe name the servers almost the same as the internal ones, but with a specific prefix or suffix, e.g. “Ext-Server-1”, etc. You then add code to detect if the current server name contains “Ext-”, then adjust the servers to call accordingly.

But it sounds like someone was not really thinking when developing those applications… That’s just bad design/programming.

3

Subject: Re

This is not my development work but something I inherited as a contractor. Some of these applications have been around since version 3 before multiple servers and best practices were even a thought. We are under a mandate to put all public accessed databases in the DMZ There is no time to perform a find and replace on all 3000 database for hard coded names and correct the code.

The solution need not be best practices. It needs to be DONE per the high-ups. I’m open to any Kludgy/Mcgyver way to make it happen

4

Subject: There’s plenty of time…

Because this will stop it going live until it’s done :sunglasses:

5

Subject: Let’s do kludgy then :slight_smile:

As a developer, I would probably use this kludgy solution:* Create the external servers in the DMZ with the same name as the internal server, but with a separate prefix, e.g. “ExtDMZ-”.

  • Create replicas of the databases on the external facing servers. Create copies of any templates and put on one of the external servers.

  • Change the template names for all those templates. Modify replication settings to not replicate design changes.

  • Use a tool like TeamStudio Configurator to perform a search-and-replace of all instances of the old server name with the new external server name on the external templates. Do the same on all databases (at least all that are not inheriting their design from a template).

I believe that should work.

If I was an admin, I might create the new servers using same server names but a different domain, e.g. /Domain-EXT and then cross certifying the servers, but you need to ask an admin about how to do that exactly.

Carl Tyler might be able to help you, he also read this forum. Otherwise there are plenty of good admins/consultants out there that could help you. Where are you located? Perhaps I know someone local.

6

Subject: Not Kludgy enough

That’s almost the correct way to do things. I had them buy Configurater as a tool to do the global find and replace of server names but they decided to move the deadline up. If I had time to do find/replace I would take out all server names in all copies and replace it with dynamic look up code. I was actually hired three years ago to come in and consolidate the three exiting servers into one when I discovered the hard coded names. They gave me one side project after another and its still not done. Now instead of saving on licensing by consolidating they now have to expand to six servers instead of the one. I’m not complaining too loud, their confusion is my extended contract.

The Admin way is something I thought of too but there is Server1/Domain in the code. Code wont run.

What if I created a middle man domain. Cross certify the old domain and new DMZ domain with the Middle man Domain and have them replicate against that. Would replication histories get screwed up with a server with the same name/domain trying to replicate with middle man right after another server of the same name tries to.

7

Subject: Just an FYI

as one of you comments make no sense. Multiple servers have been around since version 1 of Notes, so have always been a consideration.

For me personally I would try an fix the design, you’re just making the situation even more complicated by choosing the incorrect route of not fixing the design.

You’re going to get all manner of issues with replication history and things like that.

8

Subject: I meant…

In this organization…that it would become a necessity to have more then one application server. It started small and I’m thinking that they never figured they would have more then 30 employees as when they started. Now they are at 2500+ and are facing a buy-out consolidation…thus the reorg and mandate

9

Subject: Solution…sort of

I got them to agree to put all three servers in the DMZ and then allow internal employees to access it via a passthru server along with public access. There will be no internal notes servers.

Totally goes against the intent of the separation but with two different NIC cards on the passthru I was able to give a strong case of security. Sometimes its a good thing when folk don’t get notes huh?