Remote Directory issues SDS v4.2

[stevek]

Hi,

I have a situation where one of my 17 clustered 3300's believes that a HotDesk User eg 1111 is in the remote directory of controller X. All other controllers believe it exists on controller Y - the correct one.

1) I have tried adding user to controller Y and that works and is dialable from all controllers except X.

2) If I goto controller X and and remove from telephone the directory entry for 1111 it deletes it from directory but keeps a blank entry in the remote directorty.

Long story but someone messed up.

My question is, If I do a backup of controller X whilst their is a blank entry in the Remote Directory and then do a restore will it restore the blank entry?

Cheers

[ralph]

I believe there are some hidden forms that you can go into to remove the invalid RDN entry.
Unfortunately I don't know the procedures for this but I know it exist because a couple of my techs have told me they've have to use it.
But apparently it's not a very safe form to use.  - hence why it's hidden so use at your own risk.

If someone has the procedures go ahead and post it.   I'd like to document it also.

Ralph

Update: 9/6/12 - Important!   Prior to using this command it is important to note the posting in the thread by wiseguy.   You can do a lot of damage with this so use at your own risk. -Ralph

[martyn]

Don't have the answer, but I agree with Ralph on the probable solution, and would be great if someone did know how to do this and could post it!

[Mattmayn]

We have this in our local KB. I haven't used it personally so hopefully it is correct. The tech that entered it said that support told him that MCD 6.0 will make these forms public.

PuTTY into 3300 (use RAW and port 2002)
Login (use regular user/pass)
Type XSSJSB = 1
Log back into ESM
Under Maintenance and Diagnostics \Logs\SDS you will now see a folder called SDS debug.

Before closing PuTTY, type XSSJSB = 0 to disable the SDS debug.


Update: 9/6/12 - Important!   Prior to using this command it is important to note the posting in the thread by wiseguy.   You can do a lot of damage with this so use at your own risk. -Ralph

[martyn]

I have just tried that and can confirm that it does enable the SDS debug menu. I tested it on the resiliant controller that is never used just in case 

Now to go through and figure out everything that is in there that could be handy.

[stevek]

MattMayn - your a star thanks for the info. Worked a treat !!

[wiseguy]

You can seriously corrupt your underlaying database by using this command. Anyone that publish this should be responsible for the issues it can cause. The easy way to fix the problem is to delete the DN where it is. Check all switches and you might find that there is still a RDN somewhere with an other node as you had. Create the number on the node it is in the RDN table. Do a sync hosted services from that node with data repair and when finished remove. Hence problem fixed.

[ralph]

Wiseguy,
Thanks for the input.   Everyone reading this thread should take note.

Ralph

[stevek]

Somethings I discovered when entering this mode.

1) Deleting the entry from the remote directory does not delete the corresponding entries that exists in both the "GDM Hosted User Service" and the "Hosted User Service" databases - my user was a hotdesk user.
2) Entries in the GDM database take the format
43a21280-f5e0-11e1-891b-08000f29b326  4485  94ba1fe0-1dd1-11b2-b539-08000f28830f  2
First entry being host user GUID second neing directory number (called service alias) the third being the Primary Element GUID. Secondary host would be next (i didn't have one) and the last is Service Type Id.
3) I found entries made to the GDM database are replicated by the system to the NON GDM database - but not vice vera.

This is the point when you can seriously screw things up if you dont know what your doing.
Thankfully I was able to work it out a prove on a test system before hand.

So a word of caution the GDM database is the key.

[ralph]

In general: Don't experiment with a production system.

Ralph