[cisco-voip] Unity networking

[Pat Hayes]

Rasim,

I don't think it's valid to assume anything is working here, given that 
the reason Scott posted was that he was observing a problem. I 
understand you're posting based on your experiences, but I don't think 
that's a valid reason to advise someone to skip checking the basics and 
jump in to the deep end.  If Scott wants to jump in here with what he is 
observing on his system, I'm sure we could both provide better information.

Just to fill anyone else that is interested in this (and the archives), 
the way this is supposed to work is:

1. Uninstaller removes location object from AD
2. Other servers detect this and delete location from SQL accordingly 
upon synchronization with the directory

So, if after running the uninstaller and running a full sync, you still 
see the other server, you can first narrow the scope of the problem down 
by checking AD and seeing if the location object is still there. If it 
is, then, there's no point in looking at Unity yet. Either the 
uninstaller failed to remove it or the change hasn't properly replicated 
out through your AD yet. If it has been removed from AD, you should try 
forcing a resync and check your event logs for errors. If it's all 
showing up clean, but that entry is still there, then it might be time 
to start thinking about manually removing the row (or opening a TAC 
case..), but, I've yet to experience this.

As for your comment about changes in SQL automatically being pushed out 
to the directory, I believe you are mistaken. Unity's directory sync 
does indeed honor highest USNs and so fourth, but this happens above 
SQL, SQL just contains the information. If you do something like delete 
a row, that doesn't automatically increment the last USN for that 
location object (because, you know, you deleted the whole row, including 
it's LastUSN...) and it doesn't increment the last USN for the directory 
because, again, you performed an operation in SQL, not through Unity. So 
how would Unity know that is has 'newer' information? Further, while I 
don't know for sure, I'm guessing the logic built into the directory 
sync doesn't actually allow for 'pushing out a delete', rather just 
modifying values (names, etc), else, dropping a table in Unity could 
result in thousands of AD users being deleted. I wouldn't want to be the 
guy who wrote that code... Give it a try, create a test subscriber and 
delete the associated row from the subscriber table, does the user get 
deleted from AD after a sync?

Rasim Duric wrote:
> My answer to Scott's question was based on my own experience since I had
> had the same problem twice. I had spent many hours researching NetPro,
> with TAC, running ADSIEdit etc. and ended up removing those entries from
> the GlobalLocation table which TAC had also suggested. 
>
> Since Scott Voll is an experienced VOIP expert, my assumption was that
> his current Unity 4.0(5) works OK and the Uninstaller utility
> successfully completed. If this is correct, than probably his location
> objects became orphaned or stranded, and to get rid of these
> stranded/orphaned objects is through SQL.
>
> BTW, when you make a change in an SQL table this change becomes the last
> highest synced USN, so this change will propagate into AD and not vice
> versa. So there is no chance this change will come back on the next AD
> sync (at least never came back to me since I had made this change a
> couple of years ago).
>   
>  
> Rasim Duric
> Network Analyst (CCS)
> University of Guelph
> Guelph, N1G 2W1, ON
> 519-824-4120x53146
> rduric at uoguelph.ca