Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Networked Unity 3.x migration to Networked Unity 4.x Migration

Scenario: 3 Unity 3.1(5) systems networked with 4 Unity 4.05 systems. Deleted a subscriber from Unity 3.1(5) system and tryed to import subscriber in 4.0(5) system and get DTMF extsion already exists in Directory choose a different extension. Cisco Tac suggested that you cannot migrate from a seriours of 3.1(5) networked Unity servers to 4.0(5) because the database strucutres are different. Sounds a little odd but want to see if anyone else ran into this scenario. Thanks

6 REPLIES

Re: Networked Unity 3.x migration to Networked Unity 4.x Migrati

Hi -

I cannot address the issue of database structures between Unity 3.X and 4.X, but I can tell you this happens in a pure 4.X network occasionally. When you delete the subscriber from one Unity server, sometimes it takes replication time to remove the subscriber from the Global Subscriber table in Unity servers' databases. When this happens, I force directory replication on the Unity servers that still have the subscriber entry in their Global Subscriber table with the domain in which the original Unity server resides. We use DCGC Reconnect Tool for this purpose, where you force resynchronization. Another place to do this is within DOHPropTest. You want to see the successful application event AvDSAD has replicated. This has always been successful for us and allowed us to import the subscriber into the new Unity server.

Ginger

New Member

Re: Networked Unity 3.x migration to Networked Unity 4.x Migrati

Thank you for your response. We did use the DCGC reconnect tool, Initiated replication from Configuration option in Unity 4.05, used ADSI and bunnykiller to completely clean the attributes. I checked the SQL tables on the Networked Unity 4.0(5) system and I still see see the extension in the DTMFAccessID Table. We are able to successfully import the subcriber we deleted back into the old Unity 3.1(6) system without incident and we can import the subscriber using a different extension into the new system but still cannot import deleted accounts with the same DTMF Access IDs.

Re: Networked Unity 3.x migration to Networked Unity 4.x Migrati

Hi again -

When you spoke with TAC, did they indicate you could delete the DTMFAccessID entry for the user using SQL? It sounds as though it would be safe since you already cleaned the attributes of the user. I wouldn't do this without checking with TAC, but I have had to edit my SQL tables on a few occasions. Before I did, I copied the UnityDb to a spare drive as a backup. If you have a test Unity server, that might be the way to go to test.

Ginger

New Member

Re: Networked Unity 3.x migration to Networked Unity 4.x Migrati

TAC isn't sure. I went ahead and deleted the subscriber from the Global subscriber table and was able to import into the New Unity server. As the entry in the DTMF access table contains the correct extension already. Unfortunately this is not a ideal solution as there are 4 networked Unity 4.x systems and 3 networked Unity 3.1 systems and thousands of users. Could get tricky.

Green

Re: Networked Unity 3.x migration to Networked Unity 4.x Migrati

Hi Paul,

Regarding the existing user it should exist under Subscriber Table for the 3.X and in the other servers under GlobalSubscriber Table, thats why you get the error that DTMFAccessID already exists

This is expected behaviour since they r networked.

Why did u delete the Attributes for that Unity Subscriber?

I would do the backup for the 3.X servers and upgrade to 4.0.2 or later.

With that you can use GSM tool to move the subscribers and preserve Greetings|VMs.

Let me know if that works for you.

New Member

Re: Networked Unity 3.x migration to Networked Unity 4.x Migrati

That would cause downtime the customer could not afford. The solution: We removed the networking from the 4.0(5) servers. Cleaned the GobalSubscriber Table,Used Bulk delete tool to remove a test bed of subscribers from the 3.1(5) system, Used Bulk Import to import users into new 4.0(5) server. Put the 4.0(5) back into the Dialing Domain. Initiated Replication using DC/GC tool and or Doh Prop Test in the AD Monitor which repopulated the GlobalSubscriber table and all is good. I appreciate the responses.. as they all help in narrowing down the steps to take to resolve this issue.

136
Views
0
Helpful
6
Replies