Mariusz, Gorzoch tech Blog

Archive for March 2010

Ups… IT operation did change user account login name

leave a comment »

Is this a problem ? you can ask… YES it is if you are a SharePoint admin. If user login account get changed (do not misunderstand this like equal to “recreated”) for example from “domain\usr1” to “domain\usr2” then suddenly you can notice that some of your publishing sites around SharePoint can start raising “unexpected error occurred” and will not show for this user any content. What is important to notice here is that in my case this error didn’t popup jus after the change but rather around 6monts after the change!…

Reason for that is actually simply: SharePoint (actually particular site collections) need to be notified about this fact so they can update their “UserInfo” tables and start properly deliver “user profile” information.

To correct this you simply need to issue command:

stsadm –o migrateuser –OldLogn domain\usr1 –NewLogin domain\usr2 –ignoresidhistory

and you are done!… all problems get solved!

<— By the way my son find out what is a backup tape and how usefully it can be 🙂

Wish you at least the same amount of fun he has 🙂

Written by Mariusz Gorzoch

25 March 2010 at 22:46

Posted in SharePoint

Reading MSDTC log

with 2 comments

I was working today on some issues around MSDTC. Our production BizTalk for some reason couldn’t enlist transaction to SQL server. We were trying different things and on the end end-up with trying to read MSDTC log. As this task looks simple, it is for some reason not. Here is some guide what you need to do if you want to see what is happening behind the scene:

  1. If you want to analyze MSDTC log located under : “C:\WINDOWS\system32\MsDtc” you need to have tool called “tracefmt”. The problem with this tool is that it can not be just downloaded… instead of that, you need to get entire DDK package from Microsoft site (DDK site) which weight around ~700Mb, install it on your box (complete installation) and then you will find this tool under : “C:\WinDDK\7600.16385.1\tools\tracing\i386” (just grape entire content from this folder)
  2. Now you need to go to the box where your log is placed, and switch to “C:\WINDOWS\system32\MsDtc\Trace”. When you get there then past what ever you had in “i386” folder
  3. Now we are almost ready to parse. I said almost, as you cannot just use the MSDTC.log file located under “C:\WINDOWS\system32\MsDtc” (parsing that will give you empty result). If you want to see what is happening in your MSDTC you need to close current tracking session and open new one. To do so go to “cmd” and start “dcomcnfg”. When it’s open then navigate to :

“Component Services”->”Computers”->”My Computer”, right click and open properties,switch to MSDTC tab and then hit “Tracking options”. This should give you “Tracking options” window. Please notice here that all checkboxes in this window. I suggest you to do the same as it will give you the better overview.

Now, you need to click:

  • Stop Session and then “New session” (this will create you file under “\trace” folder with current date and time in name contains all trace data till the time when you clicked “stop session”
  • then perform whatever operation you need around MSDTC (all of them will be tracked)
  • perform “Flush data” and “Stop session” (this will create new trace file under “\trace” folder.

Now you should get new “trace” files under “\trace” folder:


4. Now we can perform transformation of log into more readable format. To do so you need to go to “cmd”, navigate under “C:\WINDOWS\system32\MsDtc\Trace” folder and call :

msdtcvtr -tracelog dtctrace.log.2010-03-18-15-15-47-0595-00 -o prob2
(where you need to replace “dtctrace.log.2010-03-18-15-15-47-0595-00” with your log file name)

this will cause new window to open with your trace:

have fun.

Written by Mariusz Gorzoch

18 March 2010 at 16:49

Posted in Bez kategorii

XmlAttribute & PowerShell

leave a comment »

I was trying today to retrieve attribute value from Powershell and found that for some reason $a.InnerXml, $a.OuterXml, $a.Value is note returning any value. As this is quite wired I started to dig and found the way how the value should be retrieved:

$a.get_OuterXml() or a$.get_InnerXml()

this is wired, but the way above works.

Written by Mariusz Gorzoch

12 March 2010 at 10:01

Posted in Powershell