Duplicate PC names in enterprise console

[Disclaimer: the following is my personal view; the information was gathered by snooping around(*) in the database; the conclusions are mine. (*) No electrons have been harmed in this process]

Not quite the speedy patch release I'd been hoping for, we'll just have to wait 6 or so months for it.

It's not as simple as one might assume (or wish). 

When SEC was introduced several design decisions were made. One was to make it as "universal" as possible, so it has its own communication infrastructure and doesn't make (m)any assumptions about the underlying network (physical and logical). Another one was to make it as "plain" as possible, so computers are identified by only one of their "names" - and the NetBIOS one was an obvious choice.

Over time SEC has evolved, parts have been honed, features added - and problems identified. Identical names are one problem. It is perfectly valid and reasonable to have several computers with the same NetBIOS name within an organization, SEC has to have some means to tell them apart though. A computer might have the same name when booted with one of two OSs. Of course if a computer is simply renamed you want it to stay in the group where it has been and keep it's history. AD sync brought some more problems with it. Do not forget that it has to be "fault-tolerant" (that's why "deleted" computers aren't removed from the database but only flagged and invisible). If a computer is moved out of a synced group it must not totally "disappear" from SEC along with it's history. And as it is perhaps active it contacts the server anyway. It might still be a member of the domain or it might not. There are many ways to administer IT and AD, and not all of them give optimal or even useful results. Computers are removed from the domain, renamed and joined to again and no one deletes the old computer object. So SEC detects the computer with the new name (via RMS) and and both the new and the old name in AD. As you see this is convoluted (and I've left out some other interesting cases). And so is the code which evolved over time. It was heavily modified with SEC3.0 (when AD sync was introduced) and again with 4.0 (to correct a number of issues) but it seems for 4.5 it was more or less left alone (but you see the consequences of the "less" :smileywink:). 

I think this part needs a major rewrite and this takes time. And as not only code in SEC but also tables and stored procedures are involved it's not possible to release "just a patch". This is no isolated bug - fix only this issue and at least another will pop up.    

I wonder what happens if one or both computers are deleted from the database (and why it hasn't been suggested). I have not yet found an article for this issue (the 4.5 "Known issues" only talk about actually identical-named computers and says may fail to differentiate). I must admit that I haven't tested AD sync during the Beta. OTOH I can't imagine that none of the testers did. So I think that this is not general behaviour but might sooner or later surface. It seems to be beyond repair at the moment - as painful as this is for those encountering the problem.

Christian      

[Disclaimer: the following is my personal view; the information was gathered by snooping around(*) in the database; the conclusions are mine. (*) No electrons have been harmed in this process]

Not quite the speedy patch release I'd been hoping for, we'll just have to wait 6 or so months for it.

It's not as simple as one might assume (or wish). 

When SEC was introduced several design decisions were made. One was to make it as "universal" as possible, so it has its own communication infrastructure and doesn't make (m)any assumptions about the underlying network (physical and logical). Another one was to make it as "plain" as possible, so computers are identified by only one of their "names" - and the NetBIOS one was an obvious choice.

Over time SEC has evolved, parts have been honed, features added - and problems identified. Identical names are one problem. It is perfectly valid and reasonable to have several computers with the same NetBIOS name within an organization, SEC has to have some means to tell them apart though. A computer might have the same name when booted with one of two OSs. Of course if a computer is simply renamed you want it to stay in the group where it has been and keep it's history. AD sync brought some more problems with it. Do not forget that it has to be "fault-tolerant" (that's why "deleted" computers aren't removed from the database but only flagged and invisible). If a computer is moved out of a synced group it must not totally "disappear" from SEC along with it's history. And as it is perhaps active it contacts the server anyway. It might still be a member of the domain or it might not. There are many ways to administer IT and AD, and not all of them give optimal or even useful results. Computers are removed from the domain, renamed and joined to again and no one deletes the old computer object. So SEC detects the computer with the new name (via RMS) and and both the new and the old name in AD. As you see this is convoluted (and I've left out some other interesting cases). And so is the code which evolved over time. It was heavily modified with SEC3.0 (when AD sync was introduced) and again with 4.0 (to correct a number of issues) but it seems for 4.5 it was more or less left alone (but you see the consequences of the "less" :smileywink:). 

I think this part needs a major rewrite and this takes time. And as not only code in SEC but also tables and stored procedures are involved it's not possible to release "just a patch". This is no isolated bug - fix only this issue and at least another will pop up.    

I wonder what happens if one or both computers are deleted from the database (and why it hasn't been suggested). I have not yet found an article for this issue (the 4.5 "Known issues" only talk about actually identical-named computers and says may fail to differentiate). I must admit that I haven't tested AD sync during the Beta. OTOH I can't imagine that none of the testers did. So I think that this is not general behaviour but might sooner or later surface. It seems to be beyond repair at the moment - as painful as this is for those encountering the problem.

Christian