I want & should “move my name to a new certifier”, from uwe jandt/myOU/company to uwe jandt/company - and I think these company vacation days are a good opportunity.
As I am main admin and developer (and we have a lot of dbs which has design elements signed by me) it’s surely not as easy as for a “common” user.
Are there big risks when doing it?
As far as I can see I have to refresh the ECLs of the users with my new name.
And I already put manually my new name into the admin groups and a few security fields of the server doc (just to be sure not to to lock me out).
What else should I do, to make it “as smooth as possible”?
Subject: RE: change hierarchy in the admin’s name - big risk?
Uwe, You are definitely on the right track. There are some big risks but most of them are relatively easy to overcome. Here are some tips:
Clear Admin Requests database. As much as possible, clear out any pending Admin Requests that were signed with your original name. We sometimes leave mail database pending delete’s in the AdminP database for sixty days. We have run into problems where the original requests will not process correctly because your new name is no longer the "signer of the request’. Easiest way is to simply process all requests before you complete your name change.
Database Signatures/Reader and Author Fields - You can run into some significant problems here. All of the custom databases can be re-signed with your new name but any Lotus Templates you have modified should not be signed in this fashion. Instead you may want to go into these templates and manually resave any design element saved with your old name (to keep intact the majority that are signed with Lotus Template Corporation). Updating Reader and Author fields can be a real trick, too. Even if you have set all of your databases to have the correct Administration Servers, you may not have given those servers the rights to “Update all Name fields”. Here is probably where your greatest headaches will occur.
Adminstration ECL - I would add your new name in before you have the name change and make this change under your old “trusted” name. Hopefully you are using a Security Policy that will push this down to all users. You should still expect that you will receive some “Trust Signer” style issues and may want to communicate this with your user population.
Good luck. At least you are not migrating from one Organizational certifier to a brand new one in a different Domino Domain… cross-adminp is where the true headaches really begin.
Subject: RE: change hierarchy in the admin’s name - big risk?
Thanks Kevin,
→ 1) Clear Admin Requests database.
that was a very good hint, cause I surely would have forgotten it…
→ 2) Database Signatures/Reader and Author Fields -
I will try to write an agent for this - to find me all dbs which doesn’t have the correct admin server entry and which do not have all readers/authors field chosen (or “all names fields”).
Or maybe our teamstudio tools can do this?
→ 3) Adminstration ECL - I would add your new name in before you have the name change and make this change under your old “trusted” name. Hopefully you are using a Security Policy that will push this down to all users…
Yes we have - but the problem might be that our users will return from vacation not before the 9th jan. to get the ECL changes by sec policy. On this date I will already have the new name… is this an issue?
Subject: RE: change hierarchy in the admin’s name - big risk?
Regarding DB Signatures…1) All custom DBs should probably be signed by a “Corporate Agent Runner/Org” ID file so that you don’t have to worry about this in the future. Add this Corporate Agent Runner/Org into your master Admin group with all the security rights. Then you can use the Admin client to to Sign all databases in your application servers. BUT I RECOMMEND CAUTION… This will mean that all of your agents will be signed by this entity and any @MailSend agents will start using this name as the “From” value. You may want to simply use the Admin Client to Manage all ACLs of the databases on your App Server (Use the old shift select on the Files tab in the Admin client to select large batches) and add the name of the App Server into the ACL as the Administration Server with ability to Update ALL Name fields. Be warned… this could also cause your AdminP process to take for ever to process on this server after your name change if you are listed in a ton of reader and author fields. Bottomline… This name change for you may not be something you want to slam dunk. You may want to create a system of “Co-existence” for awhile. Because “Adam Smith/Org” and Adam Smith/OU/Org are not the same people, you may want to do a bit of a trick for awhile. Have both people exist. Create a brand new Name/Org account and leave your old account. Simply change the mail routing information so that both accounts forward to the same mail database. You may get some pop-ups when people try and send you mail (which Adam Smith do you want, for example) but this may buy you some time while you fully research how many places your name has been put. You could then slowly manually update your name in groups, database design signatures, etc.
It sounds like you have thought about this for awhile. I would be prepared that if you are in a large environment (tons of critical business apps) that you look as this as a task that you don’t want to undertake lightly. I would slowy try and transition every application to be signed by a “Non-entity” like Corp Development/Org instead of being signed by your name. This will make these kinds of task much easier in the future.
Sorry to sound so concerned but name changes can go very badly.