I’ve had an issue with a new SBS2008 server, running Exchange service pack3 rollup 2 where the information store service does not start after a reboot, especially annoying after the server is rebooting with a scheduled maintenance task. Apparently this issue was fixed in service pack 1, roll up 5 but I’m still getting it 2 service packs and 2 rollups later.
Microsoft have a “fast publish” knowledge base article 940845 and the first solution is to start the services manually – really helpful! Thankfully there are other solutions that involve changing the dependencies of the services to ensure Exchange does not try to start before AD has finished.
One word of warning – using the Microsoft KB to determine the latest service pack or rollup for Exchange 2007 returns Service Pack 3, rollup 1 from http://support.microsoft.com/kb/937052. However Rollup 2 has been available since Dec 14th 2010. I’ve put a note on the original kb article but the better way to determine the latest rollup is probably to search for Exchange 2007 service pack 3 rollup
Update Knowledge base 940845 now has a fixit file you can download that will change the dependencies for you along with instructions on how to fix it manually. The article no longer has references to this issue being fixed in previous rollups – probably because this was obviously not the case.
When attempting to install Exchange 2007 sp2 on a server I was getting the error message Could not open Key UNKNOWN\Components\ 32 hex numbers \ another 32 hex numbers (see below)
This turned out to be occurring when the Rollup 9 package was being uninstalled. Checking into the registry and hklm \software \ microsoft \ windows \ CurrentVersion \ Installer \ UserData \ S-1-5-18 \ Components \ numbers \ numbers. Taking ownership of the parent registry key and then assigning my admin user full rights to the parent and cascading permissions would allow the procedure to continue a little bit further. Eventually after a couple of attempts I expanded the Components key in regedit using ctrl + and then used the arrow key to move all the way through, fixing permissions as required. The lazy way would have been to set permissions at the Components Key but that may cause other problems I didn’t really want to deal with in the future.
I have no idea why the permissions were so screwed up but I really do not appreciate wasting 4 hours on a Saturday afternoon trying to fix the issue – it took a while to debug the initial errors and then more time to run the install, find out it kept causing errors with different registry locations and then navigate through the entire component tree.
“Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later” occurs when trying to access out of office onwith outlook2007. The strange thing is that the out of office functionality through the Outlook Web Access page works as expected.
There are several documented ways to fix this, mainly ensuring that the various autodiscover urls are correct. See Proexchange.be – Your out of office settings cannot be displayed for the best document on this.
Interestingly is that if you enable debugging in outlook and try to access the Out of Office you do see the settings being pulled across in the logfile.
However I was still having this issue. From Microsoft forums on Exchange Server Clients I found that various patches to the dot net framework (oh how I hate thee) being discussed and http://support.microsoft.com/kb/952883 was the first patch that was discussed. Sure enough, installing this patch fixed the problem and what is more I didn’t even have to reboot.
The annoying thing is that the first time I had this problem (on this server) was due to a typo in the autodiscover service, then the .net framework patches were applied and the problem re-occured.
After a recent migration of mail to Exchange2007, we’ve just started getting users logging tickets where a security window pops up saying “The name of the security certificate is invalid or does not match the name of the site”. This can happen even when the client is not at their desk. It took a few seconds to work out what was causing it – the clue was that the window had an icon in the taskbar for outlook. Searching in Google found Microsoft’s KB article 940726 with the resolution to the fix which involves changing various internal url attributes.
The instructions are fairly straightforward but I wanted to see what the values were set to before making the change. As I’m not very familiar with powershell it took me a while to work out what I needed.
For the command
Set-ClientAccessServer -Identity Servername -AutodiscoverServiceInternalUri https://name.contoso.com/autodiscover/autodiscover.xml
you want to run the command
Get-ClientAccessServer -Identity Servername | fl
The pipe fl provides all the values in a list – if you don’t include this part of the code you will end up with one line containing the name of the server – a value that you hopefully know already!
I really need to get cracking on my powershell skills – I still prefer good old fashioned dos batch programming but now that we’ve started to roll out powershell across all machines, powershell skills will be in demand more and more.
The other powershell script I worked on was to retrieve a detached mailbox that was still retained in exchange, archive the mail to a pst file, move the pst file to the managers home directory and then delete the mailbox again.
The following script does this – note some paths are hardcoded and I already have a temporary account in AD called tempuser that does not have a mailbox. This is the account that the deleted mailbox is attached to.
The main disadvantage to this method is that at the end of the script all of the detached mailboxes will appear as tempuser in the exchange console. In this particular script I also do very little error checking as this was designed for my use but hopefully helps others too.
$user=$args[0] #user is the first parameter passed
$fname=$args[1] #first name
$lname=$args[2] #last name
$fullname=$fname + " " + $lname
$manager=$args[3] #manager windows accountname is the last parameter passed
if ($manager -eq $null) {exit} # if not enough parameters are provided then quit the script
write-host $user
write-host $manager
$Host.UI.RawUI.WindowTitle = "attaching mailbox to tempuser account"
$result=Connect-Mailbox -Identity $fullname -Database 'servername\First Storage Group\Standard User Mailbox' -User 'domain\tempuser' -Alias 'tempuser'
$Host.UI.RawUI.WindowTitle = "Sleeping 60 until moving mailbox"
start-sleep -s 60 # sleep 60 seconds after moving mailbox to tempuser account before doing the export
$Host.UI.RawUI.WindowTitle = "exmerging mailbox"
export-mailbox tempuser -pstfolderpath d:\mailboxes -confirm:$false
$Host.UI.RawUI.WindowTitle ="sleep 20 seconds"
start-sleep -s 20 # sleep 20 seconds after exporting mailbox to tempuser account before doing the mailbox move
$Host.UI.RawUI.WindowTitle = "Moving pst file to managers mailbox"
$newdir="\\archiveserver\c$\users\" + $manager + "\" + $user
$result=mkdir $newdir
$newpst=$newdir + "\" + $user + ".pst"
$newpst
Move tempuser.pst $newpst
$Host.UI.RawUI.WindowTitle = "disabling tempuser mailbox for reuse"
disable-mailbox tempuser -confirm:$false
Note that I use the $Host.UI.RawUI.WindowTitle statement a lot – this enables me to easily see whereabouts in the script I have got to. I much preferred to use the command title in my batch files to do the same thing. Likewise the $null = $host.UI.RawUI.ReadKey(“NoEcho,IncludeKeyDown”) is the equivalent of the batch command pause
As in my previous post I needed to obtain a list of emails that have gone through a mail server within the past 24 hours (so it can be run on a daily basis). I struggled with the code initially but ended up with the following.
$yesterday = (get-date).adddays(-1).tostring(“g”)
$rightnow = (Get-Date).ToString(“g”)
get-messagetrackinglog -Start $Yesterday -End $rightnow -EventID RECEIVE -Result size 5000| select-object EventID,Sender,@{name=’Recipients’;expression={[string]::join(“;”,($_.Recipients))}},MessageSubject,TimeStamp | export-csv receive.csv
get-messagetrackinglog -Start $Yesterday -End $rightnow -EventID SEND -Resultsize 5000| select-object EventID,Sender,@{name=’Recipients’;expression={[string]::join(“;”,($_.Recipients))}},MessageSubject,TimeStamp | export-csv send.csv
My next step is to automate this and send it via email
Trying to export an Exchange2007 mailbox using the export-mailbox cmdlet I was getting the error message “Failed to copy messages to the destination mailbox store with error: MAPI or an unspecified service provider. ID no: 00000000-0000-00000000, error code: -1056749164″
A lot of the tips online suggested that I excluded the inbox folder, but that doesn’t help as I needed to export the entire mailbox as this was for a user who had left the company.
Microsoft has a kb article on this and states the problem is fixed with Rollup4 for Exchange, but I was already on Rollup5.
Thanks to kyBOSH on the Technet forums , it turns out that I needed to give my account FullAccess to the mailbox using the command “Add-mailboxpermission account -accessrights fullaccess -user myaccount” Obviously you need to replace account with the accountname of the user that is being exported and myaccount is the accountname that is doing the export.
Whilst searching for these results I discovered how bad Microsoft’s Live Search is.
The initial search for “-1056749164″ on Technet came up with 619000 results (although when I reran it later it dropped to 512000!).
As the results were completely useless I expanded the search to the entire internet – this time the search returned zero results!
In my newly installed exchange2007 site I also had an exchange2003 server that handles all the incoming/outgoing mail apart from the test user that I had moved to the 2007 server. Unfortunately I could not send mail to the 2007 user but I could receive mail from this user. T here was a lot of postings on the internet and various forums for solutions for a similar problem but normally in the opposite direction.
After a post at petri (2nd posting down) I deleted my smarthost setting on the virtual server on the 2003 machine and mail started flowing. Now I can progress in my mail migration. Many thanks to Andy at Petri for the answer on this one.
Annoyingly this did come up in the best practise analyzer, but only as a warning. As the smarthost had been working I left it alone – I really should have known better.
