Our client currently in /test domain and hence their id displays as ‘Steve Waugh/Test’. They want to see their id as ‘Steve Waugh/Prod’. i.e, they want their domain name should change to Prod from Test.
Only way I know to do this, install a new server with Domain ‘Prod’ and create all 416 users. Assign all access to db once again. This would be very time-consuming and inefficient also.
Subject: RE: how to change Domain name /old_company to /new_company
Thanks Joe for the response.
From the previous posts, I get some help but still Im afraid I wont miss something. I’ll follow these steps. Pls let me know where Im wrong or what I left.
Install a new server to get the new cert id.
Recertify users from /old_company to /new_company
Update ACLs of existing dbs (or AdminP will handle this)
Inform users that they have to update their location document on their own.
Update people, group, connection documents in the Address Book (/new_company)
Please Guide me for :
– What all documents I need to update from /old_company to /new_company
Subject: RE: how to change Domain name /old_company to /new_company
You ask:What all documents I need to update from /old_company to /new_company
Reply
Certify those document you want to be under the /new_company org.
You ask:
What all other activities I need to do
Reply
You need to plan this out carefully. There is trusts which need to be granted. I would make sure the /new_company org will accept anything from the old certifier. Update the ECL. As always I would urge you to test and do this on a low scale before you change your production environment.
The people’s local location document should update on their own. Adminp will manage that. Changing an org has to be a planned process because it is going to impact the server, people, the application ACLs, and the desktop ECL.
… but am I missing something here?Assuming it is the Organisation you want to change for the users why not simply create a second Organisation (and therefore certifer ID) and re-certify the users with the new certifier. Obviously you would create a couple of test users first and prove the process with those. I would also suggest making a full backup prior to making any changes.
I wouldn’t suggest recertifing the server, I’d leave that with the existing name.
Adminp will take care of the rest.
No need to create new servers, trusts, etc, etc.
If it is the Notes mail Domain that needs changing then this can be a painful process.
Technically you are not creating a new server if you just certify the old id with the new cert.id.
If you create a second org that is not the same. A second org is Joe Public/SecondOrg/FirstOrg.
Technically speaking, you can not certify the server id when the server is running as well. If you do the id will not be updated. So it is not that simple. Yes adminp will process everything be at the core you have to update the server id’s when the server is offline.
The full back is agreed, but before you even start that you need to test to make sure you have everything understood. There is no harm to create a new Org on a test box and start there.
I’m not saying re-certify the server. There is no need to, just leave that the same. I am saying that to get from Jo Bloggs\Org1 to Jo Bloggs\Org2 all you have to do is create a second organisation in the existing Domino Directory(NB - NOT an organisational unit) and re-certify the users with the new certifer ID. In your example you are getting confused between Organisations (O’s) and Organisational Units (OU’s).Adminp does it’s stuff and (assuming R5 or higher) the users’ location document also gets changed if needs be.
In most practical example people use one organization. Rather it is possible.
How do you counter the trust between the 2 orgs then? Since Jo Bloggs/Org1 is now recertifed to be Jo Bloggs/Org2 will be allowed to log onto ServerName/Org1.
I see some risk, because people are going to forget the hierarchy. My advice here is from the stand point that many people take everything literally. Thus why I gave the advice to recertify the servername.
And (agreed) that it was pointed out that the lcoation document would be updated.
No issue with trusts at all. All the normal security configuration applies and would need changing depending on the existing configuration. e.g. */Org1 might be in who can acccess the server field in which case this field needs modifying. My point is that the change that is required (i.e. from one O to anotherO) does not need to be as complicated as is being made out. Yes some configuration will need changing but nothing too complicated needs doing.
As for the server name I generally create a seperate OU for servers anyhow called something like SVR, therefore the server name would be server1/svr/org1. The users would be something like Jo Bloggs/Marketing/Org1. This never gives an issue to users since generally they don’t need to know the full name of the server.
