There are some issues and all attempts to resolve them are causing inconvenience or even jeopardizing the production becausea wrong step might result in the removal of target objects from the GAL. What can be done to prevent this from happening?
When QCS (Quest Collaboration Services) creates and matches objects it uses a matching attribute (by default Extension Attribute 10) and populates it with unique informationThis allows the tool to find and work with this object after the first initial matching occurred. The information inside the attribute is unique in the environment but not unique when talking about QCS. In other words - when eg. a new QCS instance is installed this new instance can easily use the existing object and all the information. All the values like EA 10 and proxy addresses which were added and/or populated by a previous QCS instance will stillbe used by a new QCS instance.
Knowing all this the most elegant way when troubleshooting issues could be to install and use a new QCS instance. Steps could be the following:
1. Instruct the subscriber not to unsubscribe from any publications.
2. Temporarily disable all existing publications (disabling a publication just puts the synchronization on hold, it does not remove objects from the GAL and does not delete any attributes).
3. Stop QCS services and set them to disabled, to avoid a start by mistake (eg. after a reboot).
4. If needed clean up and modify target objects (if there were any issues).
5. Install QCS on another computer, use the same service account, the same mailbox. A new key will be generated.
6. Create the needed publications again.
7. If populating the publication with members is an issue then before disabling the old publication export the members to a txt file and use this file to populate the new publication.
8. Instruct the subscriber to subscribe to newly created publication(s).
9. If unsure start with one user, add the user and if the results are satisfactory then proceed and add all users.
10. QCS will then find old existing stub objects on publishers side (assuming they were not removed or moved out of the original OU) and QCS will re-use them.
If one can afford to lose the objects from the GAL for a short period of time then existing stub objects can be deleted, QCS will re-create them shortly afterwards. There are many advantages when using this approach, some of them are:
-At any given time one can go back and activate the old instance without jeopardizing the production
-If new instance works as expected then as end-result you get a new, fresh, slim and healthy QCS DB.
This approach helps to narrow down the problem and to answer the question whether the issue is QCS instance and DB related or it is an environmental issue. A new instance helps to resolve all issues like flush the information about old matching rules, old errors and issues which might be still present in memory and sometimes in the product DB.