No, not me\u00e2\u20ac\u00a6 I\u00e2\u20ac\u2122ve been happily married for 19 years.. it\u00e2\u20ac\u2122ll be 20 while I\u00e2\u20ac\u2122m at the SharePoint Conference too, but that\u00e2\u20ac\u2122s another story.. watch this space for more details on that one..<\/p>\n
The marriage part in this post is something that has been the bane of SharePoint admins for a long time, and that is how to manage when members of staff get married and change their surnames. How this affects you really depends on how your company handles the event. Do they create a new AD account with the new name, do you keep the old AD account and alias the e-mail box? Or do you rename the AD account to the new surname.<\/p>\n
The company that I\u00e2\u20ac\u2122m doing some consulting for at the moment had these problems, but with a twist. They fully understood what needs to happen in SharePoint 2007 when an AD account is changed. They were using a profile import, then the migrate user command.. (I\u00e2\u20ac\u2122m not convinced this step is required.. but I need to test further.) and finally they were making sure that the internal timer job \u00e2\u20ac\u0153Profile Synchronisation\u00e2\u20ac\u009d for the web application was running hourly.<\/p>\n
The upshot is, Jane Doe, became Jane Smith across all the sites she was active in, visible in the hidden user list and displaying the correct details in the user menu.<\/p>\n
As soon as she clicked through to the LOB system though she received access denied. The Kerberos tickets were valid on her client machine and SharePoint was happy, however the LOB reported invalid login back to the user.<\/p>\n
On investigation, we discovered that the LOB was reporting an attempted login by JANE DOE, who didn\u00e2\u20ac\u2122t exist now, therefore it couldn\u00e2\u20ac\u2122t match her account to it\u00e2\u20ac\u2122s list of acceptable users. After a bit of binging around, we came across http:\/\/support.microsoft.com\/kb\/946358<\/a> which describes the problem nicely.<\/p>\n Disabling the LSA cache achieved what we wanted, however I\u00e2\u20ac\u2122m always loathe to disable caching willy nilly.. after all caching is there for a reason and usually a pretty good one. In this case it prevented the LOB system from placing a call to AD with every transaction, which prevents an awful lot of AD traffic.<\/p>\n We restored the cache and ran another user through the system, changing their name and ensuring that they couldn\u00e2\u20ac\u2122t log in to the new system. After much testing, we discovered that if you run the following 2 lines of powershell, it re-writes the cache entry in the LSA cache, updating it with the correct username. Running this on the Web servers for the LOB system updated the cache properly and the user logged straight in.<\/p>\n This has now been adopted into the clients account name change process.<\/p>\n$objuser = new-object system.security.principal.ntaccount "domain\\<<\/span>new<\/span> account<\/span> name<\/span>><\/span>" \r\n$objuser.translate([system.security.principal.securityidentifier])\r\n<\/pre>\n