06-22-2012 11:40 AM - edited 03-19-2019 05:09 AM
Hi,
A customer has a Unity 5.0(1) for Domino server. They want me rebuild the server with a different name and as a member of a different domain.
To do this I have to rebuild the server from the OS up and then restore from a DiRT backup. Before taking the DiRT backup I need to make sure that dbWalker does not report any errors.
When I run dbWalker I get the errors shown below:
@PrimaryServer = [TG-WILTS-UM1]
Primary server name found = [TG-WILTS-UM1]
SchemaMajorVersion = [ 3]
SchemaMinorVersion = [ 21]
1654:(error) no Unity messaging system account found in the subscriber table (subscriber type of 0). This can mean that no one has called into Unity and accessed their inbox yet. Normally a restart of the Unity server and calling in will automatically create this account. If not, please contact TAC for assistance
Checking LastModifiedTime column for all entries in the Configuration table
Alias=Unity_TG-WILTS-UM1
Display Name=Unity Messaging System - TG-WILTS-UM1
Jump to this subscriber in the SA using this link: Open SA to this subscriber
1520:(error) subscriber has NULL for their primary call handler reference - this is not a valid subscriber.
You will need to delete and recreate this subscriber. If you cannot delete the subscriber in the SA directly you can remove this subscriber's row from the Subscriber table in the UnityDB database in SQL.
If you are uncomfortable editng SQL directly, please contact TAC. Be sure to get a backup of your system using DiRT before editing anything in SQL on your own.
1342:(error) COS reference is NULL. You can fix this by selecting a valid COS object on the profile page for this subscriber in the SA.
Location Object Alias=default
Subscriber has no voice name recorded
Location object display name=Default
Subscriber is assigned to language=English (United Kingdom)
1353:(warning) the Switch ID for this subscriber is set to NULL. This means it will default to switch 0. You can fix this by selecting a valid switch on the profile page for this subscriber in the SA.
Subscriber has no private lists
1435:(error) No notificaiton devices found for this subscriber. This is an unusual error to encounter on a production system.
You will need to delete and recreate this subscriber. If you cannot delete the subscriber in the SA directly you can remove this subscriber's row from the Subscriber table in the UnityDB database in SQL.
If you are uncomfortable editng SQL directly, please contact TAC. Be sure to get a backup of your system using DiRT before editing anything in SQL on your own.
Checking subscriber exit destination
1388:(error) subscriber's exit action is set to NULL. You can fix this by selecting a valid destination on the conversation page for this subscriber in the SA
Alias=USbms_TG-WILTS-UM1
Display Name=USbms - TG-WILTS-UM1
Jump to this subscriber in the SA using this link: Open SA to this subscriber
1520:(error) subscriber has NULL for their primary call handler reference - this is not a valid subscriber.
You will need to delete and recreate this subscriber. If you cannot delete the subscriber in the SA directly you can remove this subscriber's row from the Subscriber table in the UnityDB database in SQL.
If you are uncomfortable editng SQL directly, please contact TAC. Be sure to get a backup of your system using DiRT before editing anything in SQL on your own.
1342:(error) COS reference is NULL. You can fix this by selecting a valid COS object on the profile page for this subscriber in the SA.
Location Object Alias=default
Subscriber has no voice name recorded
Location object display name=Default
Subscriber is assigned to language=English (United Kingdom)
1353:(warning) the Switch ID for this subscriber is set to NULL. This means it will default to switch 0. You can fix this by selecting a valid switch on the profile page for this subscriber in the SA.
Subscriber has no private lists
1435:(error) No notificaiton devices found for this subscriber. This is an unusual error to encounter on a production system.
You will need to delete and recreate this subscriber. If you cannot delete the subscriber in the SA directly you can remove this subscriber's row from the Subscriber table in the UnityDB database in SQL.
If you are uncomfortable editng SQL directly, please contact TAC. Be sure to get a backup of your system using DiRT before editing anything in SQL on your own.
Checking subscriber exit destination
1388:(error) subscriber's exit action is set to NULL. You can fix this by selecting a valid destination on the conversation page for this subscriber in the SA
These errors are associated with the Unity Messaging and UnityBroadcast system accounts so I do not think that I can follow the recommendations about deleting and recreating them.
Does anyone have any recommendations on how to fix this?
Thanks
Solved! Go to Solution.
06-22-2012 12:18 PM
Been a long, long time since I've looked at a Domino backed Unity setup but I believe those errors all stem from the first one - it's expecting those system accounts to be of type "0" which indicates they are "special" and don't need those exit destinations and such (i.e. you can never call in as one of those users and log in hence no need for a COS or an exit destination etc...).
Not sure right off hand how/why those accounts would not have the types correct - but DiRT should handle this on restore - the system you install will have those system account built as normal (i.e. as they should be) and DiRT's logic is to find the corresponding user entries by name/alias and update their settings - it specifically leaves those system users alone in this process - so I think you should be ok in this case.
06-22-2012 12:18 PM
Been a long, long time since I've looked at a Domino backed Unity setup but I believe those errors all stem from the first one - it's expecting those system accounts to be of type "0" which indicates they are "special" and don't need those exit destinations and such (i.e. you can never call in as one of those users and log in hence no need for a COS or an exit destination etc...).
Not sure right off hand how/why those accounts would not have the types correct - but DiRT should handle this on restore - the system you install will have those system account built as normal (i.e. as they should be) and DiRT's logic is to find the corresponding user entries by name/alias and update their settings - it specifically leaves those system users alone in this process - so I think you should be ok in this case.
06-22-2012 12:52 PM
Jeff,
Thank you very much for your answer.
I was expecting a busy night liasing with TAC about this but thought I'd put it on NetPro first. My lucky day that you saw it and kindly took the time to respond.
I will now enjoy my evening before starting the migration tomorrow
Thanks again
James
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide