Poznáte to.
Občas sa stane niečo, s kým nik pri návrhu nerátal a hoci v normálnom živote je to bežná vec, pre nejaký program to môže byť neprekonateľný problém. Vtedy sa dá problém odbiť hláškou : Not supported by design, ale občas to nefunguje, najmä ak user je z vašej firmy a stretávate ho temer denne. 
Tak napríklad. Včera za mnou prišiel kolega a hovorí : Máme menší problém. (Vedel som, že je zle.) Už teraz pani, nazvime ju Otília sa vydala a ako napotvoru, zmenila si priezvisko. Náš admin jej na domain controlleri zmenil dokonca aj prihlasovacie meno a tak sa teraz hlási novým. Poznám Active Directory len pokiaľ musím, ale predpokladám, že každý user má nejaké GUID, ktoré ho identifikuje. A teda DOMENA\meno je len string, ktorým sa hlási do domény, spolu s jeho pwd. GUID mu ostane naveky a ak ho aj disablujeme, ostáva tam, nech sa vie, kto objekt vytvoril, nech máme na koho ukázať prstom. Podobne je to v CRM. CRM 4.0 stavia na AD a preto po zadaní DOMENA\meno si pri vytváraní nového usera potiahne bližšie informácie logicky z AD. Ako sa u nás na dedine hovorí, so far, so good. Pani sa teda overila voči doméne a nakopla svoj shiny new IE8 (the new amazing one 
, jaj či toto používa asi iná firma) a CRM 4.0 ju privítalo, no pod starým priezviskom. OK, hybaj teda do users a prepíšeme Otílii priezvisko, no po zmene doménového mena sa CRM ohlásilo chybou v tom zmysle, že user s rovnakým doménovým kontom už existuje. Bohužiaľ, neprezieravo som si screenshot neuložil 
. Každopádne CRM vedelo, že konto existuje v doméne, no nechcelo nám dovoliť meniť jeho hodnotu na aktuálnu pre našu pani. Nejakým legálnym spôsobom cez GUI CRM 4.0 som nevedel zmeniť jej doménové meno a nakoniec pomohol len SQL update nad tabuľkou SystemUserBase v stĺpci DomainName. A prečo tieto peripetie? Pretože ak máte nad CRM 4.0 reporty, tieto vám samozrejme nebudú fungovať, pretože CRM odovzdávalo reporting services doménové meno ktoré už neplatilo. Aspoň že na to SQL sa dá spoľahnúť.