Exchange 2003 SP2 move mailbox issue (Guid-ReplID Caching) Part 2

This little script will do all the work for you.. Some of our servers have nine stores so this takes a second to run as opposed to minutes doing it manually.


const HKEY_LOCAL_MACHINE = &H80000002
If (Wscript.Arguments.Count)<>2 Then
WScript.Echo ("Usage : cscript guidstore.vbs -s ")
WScript.Quit(1)
End If
If lcase(WScript.Arguments(0))="-s" Then
strcomputer=WScript.Arguments(1)
End If

Set StdOut = WScript.StdOut

Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_
strComputer & "\root\default:StdRegProv")
strKeyPath = "SYSTEM\CurrentControlSet\Services\MSExchangeIS\" & strcomputer
oReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys
For Each subkey In arrSubKeys
StdOut.WriteLine subkey
SubKeys = "SYSTEM\CurrentControlSet\Services\MSExchangeIS\" & strcomputer & "\" & subkey
strValueName = "Guid-Replid Caching"
dwValue = 0
oReg.SetDWORDValue HKEY_LOCAL_MACHINE,SubKeys,strValueName,dwValue
Next

Exchange 2003 SP2 move mailbox issue (Guid-ReplID Caching)

Summary
After moving mailboxes to an Exchange 2003 SP2 server, Outlook users may experience a crash when changing folders. The crash is a stack overflow caused by corruption in the GUID/Replid Mapping (GRM) cache on the target server. Remounting the mailbox store or restarting the Information Store service will resolve the crashing for affected users. Some users that have experienced the crashing problem may also experience problems with duplicate folders, delegate issues, and Free/Busy information. These problems persist after the restart and must be manually corrected.

More Information
In Exchange 2003 SP1, the GRM cache is disabled by default. In Exchange 2003 SP2, it is enabled by default. Enabling the GRM cache can lead to problems during mailbox moves to a target SP2 store. Its purpose is to handle lock contention that can affect performance during the move mailbox operation. The odds of the perf hit being severe are very low, but there is a slight chance. In most scenarios, a chance of slow is better than the alternative so we are working on a post-SP2 hotfix to disable it by default. In the meantime, you can disable the GRM cache on a per-database basis with the following registry value:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\[server name]\Private-[store guid]
Value Name: Guid-Replid Caching
Value Type: DWORD
Value Data: 0

Notes
- For the registry change to take effect, remount the affected mailbox stores.
- The hotfix is still under investigation. There is no ETA at this time for its release.
- Disabling the cache will not affect users that have already experienced the problem, it only prevents mailboxes from getting into the problem state while moving them.

Correcting SIP Addresses

If a user changes his email address then he may well not be able to log into LCS anymore due to that not matching his logon.

This script cycles AD and checks for mismatches. If you specify /commit it will write the changes back to AD.

'==========================================================================
'
'
'
' NAME: SIPFix.vbs
'
' AUTHOR: Stuart Bennett
' DATE : 26-05-2006
'
' Usage: sipfix.vbs

' e.g. sipfix.vbs out.csv /write
'
' COMMENT: Update all those pesky sip addresses to primary SMTP.
'
'==========================================================================


On Error Resume Next
' Change the xx throughout to your domain name..
OUMasterPath = "LDAP://OU=User,OU=Accounts,DC=emea,DC=xx,DC=com
Dim filename : filename = LCase(Trim(WScript.Arguments(0)))
Dim commit : commit = LCase(Trim(WScript.Arguments(1)))
Dim oFS : Set oFS = CreateObject("Scripting.FileSystemObject")
Dim fout : set fout = oFS.OpenTextFile(filename, 2, True, -2)
On Error GoTo 0

Set objTOPOU = GetObject(OUMasterPath)
For Each objOU In objTOPOU
wscript.echo("Processing Site : " & objOU.name)
Call SubOU(objOU.Name)
Next
fout.Close


Sub SubOU(theOU)
strOUPath = "LDAP://" & theOU & ",OU=User,OU=Accounts,DC=emea,DC=xx,DC=com"
Set objTestOU = GetObject(strOUPath)
For Each objUser in objTestOU
GetSIPContact fout, objUser
Next
End Sub

Sub GetSIPContact(fout, objUser)
On Error Resume Next
objUser.Get("msRTCSIP-PrimaryUserAddress")
if (Err.Number = 0) Then
SIPName=LCase(objUser.Get("msRTCSIP-PrimaryUserAddress"))
PrEmail=lcase(objuser.mail)
SIPName=Replace(sipname,"sip:","")
If trim(SIPNAME) <> trim(PrEmail) Then
wscript.echo(objUser.DisplayName & ";" & SIPName & ";" & prEmail)
fout.WriteLine(objUser.DisplayName & ";" & SIPName & ";" & prEmail)
If lcase(commit)="/write" Then
realSIP="sip:" & prEmail
wscript.echo ("Changing " & objuser.name)
objuser.PUT "msRTCSIP-PrimaryUserAddress",realSIP
objuser.setinfo
End If
End If
Else
Err.Clear
End If
On Error Goto 0
end Sub

Mounting an exchange 2003 database on a different server.

I had always assumed that to recover a a mailbox when the original MsExchangeGUID attached to the AD account was lost would require a replica AD and Exchange 2003 server to be built.
This is just not the case and I've already restored several mailboxes by relinking them to different AD accounts in entirely seperate forests.

the key to it is LegacyDN.exe,a super tool which can be downloaded from www.microsoft.com/exchange. Don't ever run it in your production environment though..
Once in possesion of this, all you need is the .edb and .stm files.

I have an entire Virtual Server 2005 environment now for this. Create a new AD (call it whatever you want), extend it and install Exchage 2003. Call the Exchange org whatever you want, and the server itself can be whatever.

Once all is installed, I'd copy the VS2005 disks so you always have a ready environment for re-testing.

Running legacyDN.exe, you can then alter, the Orgname, the AG name, and the all importany LegacyDN name to match where the original DB came from. Once done, create a new store, but don't start it. Place the origianl DB's files in the location of the new store. Start it, run mailbox cleanup agent, then relink to any AD account you've created in your new directory.
Export with exmerge and job done.

I know RSG's save us in almost all cases, but exmerge will not see data when the msExchangeGUID cannot be matched to a AD account.

With the Virtual Server disk images in place, I can recover any mailbox in about 10 minutes these days.

Long live the illusion of identical environments for restores required, NOT ! If you want the full step by step guide, drop me an email.

Mounting an exchange 2003 database on a different server.

I had always assumed that to recover a a mailbox when the original MsExchangeGUID attached to the AD account was lost would require a replica AD and Exchange 2003 server to be built.
This is just not the case and I've already restored several mailboxes by relinking them to different AD accounts in entirely seperate forests.
the key to it is LegacyDN.exe,a super tool which can be downloaded from www.microsoft.com/exchange. Don't ever run it in your production environment though..
Once in possesion of this, all you need is the .edb and .stm files.
I have an entire Virtual Server 2005 environment now for this. Create a new AD (call it whatever you want), extend it and install Exchage 2003. Call the Exchange org whatever you want, and the server itself can be whatever.
Once all is installed, I'd copy the VS2005 disks so you always have a ready environment for re-testing.
Running legacyDN.exe, you can then alter, the Orgname, the AG name, and the all importany LegacyDN name to match where the original DB came from. Once done, create a new store, but don't start it. Place the origianl DB's files in the location of the new store. Start it, run mailbox cleanup agent, then relink to any AD account you've created in your new directory.
Export with exmerge and job done.
I know RSG's save us in almost all cases, but exmerge will not see data when the msExchangeGUID cannot be matched to a AD account.
With the Virtual Server disk images in place, I can recover any mailbox in about 10 minutes these days.
Long live the illusion of identical environments for restores required, NOT !

Oliver Bennett

I am a dad !!!

Www.oliverbennett.com

The WMF Virus Emails.

Oooh, was I first to receive one of the emails to use the new WMF exploits. check the text, it's quite convincing. And don't click the link, though I've left it in for those more adventurous types.

From a certain Mr Gordson.

Hello,

We are very sad to say that over the New Year the Campus was subjected to
several acts of mindless vandalism. As well as bricks being thrown through
windows, several members of staff have reported their cars as being the
subject of practical jokes. Some of these cars were filled with water whilst
others had graffiti daubed across them. We have uploaded the pictures of the
graffiti here http://playtimepiano.home.comcast.net/ in the hope that someone
may recognise the culprits work. If anyone can shed any light on this unfortunate
incident could they please contact the main office as soon as they have time.



Many Thanks & Best Regards,

Professor Robert Gordens
Yale