unity upgrade from v246 to v313 and digital networking

[jseinfeld]

several months ago we did a forklift upgrade from v2.4.6 to v3.1.3 on our two unity servers that have e55 off box in the same e55 site. the two switches are of the same type, with one unity server per switch. for the forklift operation we used jeff's export and import utilities. that all seem to work fine.

now, we are about to enable digital networking. we have a test unity server that we enabled digital networking on. from the test server we can dial by name and dial by extension only a subset of the subscribers on our two production unity servers.

after much finger pointing between the switch and unity folks we took a look at the unity db sql tables "globalsubscriber" and "subscriber" on the production server. we noticed that for most of the subscribers that the attribute "xferstring" has a NULL value. the rest of the subscribers had a value for xferstring that correspond to their dtmf.

at first blush, it appears that the imported subscribers from the forklift import, have a NULL value for the xferstring, except for the subscribers whose transfer string was touch within saweb at some point in time after the forklift.

from the test unity server, we can successfuly dial by name and extension those subscribers with a globalsubscriber non-null valued xferstring. we cant dial by name nor extension those with null valued xferstring.

from saweb on a production unity server we manually changed the transfer string for one of the subscribers with a null xferstring. we waited for e55 replication and a little longer for unity synchronization. subsequently the test unity server table globalsubscriber had an updated xferstring value for the subscriber. afterwards we could dial by name and extension of the subscriber.

we have a couple thousand of entries with null valued xferstring. is there a program available to fill those values in for us? if not, can someone give us the sql commands to perform the update?

also, is there way to manually force a e55 synchronization with unity?

[lindborg]

Nice troubleshooting there...

That's interesting, no one's reported anything like that but I'll bet you dimes to dollars it's been in there from day one on all imports like that since the 2.x DB didn't have this value and I don't think the global table value gets updated until it changes on the local subscriber table - I'll have to chat with the DB folks about that one...

You can fix this up by running this query on both boxes – it’ll force the local subscriber table XFerString to update which will kick a trigger that will push it into the GlobalSubscriberTable

UPDATE Subscriber

SET subscriber.XFerString = callhandler.dtmfaccessid

FROM Subscriber INNER JOIN CallHandler

ON Subscriber.CallHandlerObjectID=CallHandler.CallHandlerObjectID

WHERE Subscriber.SubscriberType='1'

The trick is forcing it to write into the directory after you’ve updated the local SQL data – if you don’t the next time we synch with the directory any changes out there will over write the changes you just made. The SA cheats and goes through the DOH interface which handles this for them on the back end so you’ll have to kick of the synch process manually. You can do this by running the setup.exe under the \commserver\configuration setup folder with the “-sync” command line parameter. It’ll push all the updated info into the directory which may take a little bit depending on how big your database is.

To force Unity to read the directory without waiting for our sync time to come around you can use DOHPropTest – read only mode is no problem, no need to supply the password. On the right click the “AD monitor” (for Ex55 I’m not sure what it’s called right off hand but it should be obvious) – in the resulting dialog there will be two buttons for “resync now” and “total resync” – I usually just whack them both since if you put a gun to my head I couldn’t define the difference between the two functions. And there’s no way to tell it’s done, but it goes pretty quick.

[oliviers]

I won't put a gun to your head Jeff, but I can tell you the difference between a resync and a total resync.

With a resync, it's a incremental resync. The query that the directory monitor will make will only request changes on Unity objects that have happened since the last sync cycle.

With a total resync, the directory monitor asks for changes on Unity objects since the dawn of the system's time. You can expect to have many more results returned, and more processing with a total resync. The other thing that the total resync does is it forces the update to the Unity database. Unity normally checks the USN of the object returned from the query and compares that to the objectChangedId value for the object in SQL. If the USN of the object is higher than what's in SQL, then the changes are committed to the database (this would mean that the object changed in the directory outside of Unity). If the USN is equal or lower than (it should never really be lower than), then the changes are not committed to the database. The "total" resync disables the USN check and just lets the update rip.

Now having said that, there's a slight anomally with the E55 monitor in 3.1.X where it does not do the "force update".

The easiest way to tell either sync is done is to check the last synced USN value for the directory monitor in question before the sync is kicked off. You should be able to get this from DPT as well when you grab a monitor. You can also get it from the registry if you know where to look. Kick the sync request off, and when that USN value changes to a higher value, the sync is done. That's the case with a full or "normal" sync. The monitors don't update that USN value until the entire sync process is done.

...Or just watch the TaskManger and wait for the directory monitor's CPU time to go back to "0".

[jseinfeld]

Many thanks. The sql update worked fine and callers can now address by name or extension. We did modify the where clause adding "and subscriber.xferstring is null". We didnt want to modify subscribers who had change their transfer strings.