Retrieve Mailbox Migration errors for Office365

When you have a lot of mailboxes to migrate, Microsoft’s provided method of viewing the errors involves a tedious amount of clicking by logging into the portal, selecting Exchange, Migration, View details, scroll down to find a failure, select the user, click view details.

Viewing Migration status in Office365

 

Rather than use the tedious method of going into the details, selecting a user and then viewing details, run the following powershell script (once connected using the previous office365 connection script)

get-migrationuser -status failed  | get-migrationuserstatistics | select identity,emailaddress,recipienttype, error,bytestransferred |export-csv c:\temp\migrationstatus.csv

I also have a simple loop that gets me the status once an hour. Obviously change the email address’s appropriately.

while (1)
{
$a=(get-migrationuser | out-string)
send-mailmessage -to [email protected] -subject “Company Migration Stats” -from [email protected] -smtpserver my.mailserver.com  -body $a
start-sleep -seconds 3600
}

Find mailboxes that have the Email Address Policy disabled

Took me a while to work this one out but the powershell line for this is

get-mailbox | where {$_.EmailAddressPolicyEnabled -eq $false}

Or you could switch it to the following but this is less easy to read for junior techs to understand as the ! is not necessarily obvious.

get-mailbox | where {!$_.EmailAddressPolicyEnabled}

Pimp your Powershell Prompt

I use powershell a lot at work – I’m not a guru by any means and I often find it hard to remember the commands I have run in a session, either for future use or for documenting in my time sheet (which also acts as a point of reference for future helpdesk tickets).

When I started going through the Powershell in a month of lunches book (which I highly recommend or the Powershell v3 book) I decided to use the start-transcript commandlet to record all my powershell activities.  This worked very well until I would scroll through several screens worth and then forget what file I had saved my transcript too.  There was also the possibility of forgetting to transcript everything.

By using the powershell profile file I was able to enter the commands to automatically set the transcript to the current date. I was then able to modify the title of the powershell prompt to display the filename so I could always see where the file was saved with the added bonus of a variable being used if I ever needed to open the transcript

My next step was to include the time in the powershell prompt – this enables me to go back through the transcript and see how long it took to run the commands for my timesheet entries.  Remembering back to the good old dos days, I remembered the prompt command. A quick bit of experimenting with the Date command I had the current time displayed at the beginning on the Powershell prompt. Note this is displayed after the previous command is run, so technically it’s not the exact current time, but the time that the prompt was displayed on the screen.

The final profile script can be copy/pasted into notepad by typing in

notepad $profile

is as follows:-

cd \andy\powershellinamonthoflunches

$log="c:\temp\powershelllogs-" + $env.username + (get-date -uformat "%y%m%d-%H%M") + ".txt"
start-transcript $log
$host.ui.rawui.WindowTitle = $log

function prompt
{
write-host ((Date -uformat %T).ToString() + "PS " +$(get-location) + ">") -nonewline
return " "
}

This ends up with a powershell prompt that looks like the following. Hope this brief posting inspires you to change your powershell prompt to be even more useful for you.

 

Powershell prompt with the filename in the title and current time in the prompt

 

Fixed – Office365 journalling does not work for one user

I’ve been working on a case with Microsoft’s Office365 support for several weeks trying to find out why email sent *to* a particular user was not being journalled. All the other mail seemed to be journalled to the external recipient, email from the user was working, just not email to that user.

The experience was quite frustrating as Microsoft’s support were terrible at calling back and could not grasp the concept of email tracking. Their solution after making a change was to wait a day to see if it was fixed although it was quite apparent that the Microsoft servers were not even trying to send the email (by looking at the Trace Logs you can see what email was being sent and received).

After checking the connectors were setup, mail properly scoped, the user had no rules on their mailbox, Microsoft’s solution was to delete the mailbox and reset it up again.  Not so easy when the mailbox/user is federated with Active Directory and the user happens to be the owner of the company. That was not a conversation I was going to have with them!

The only thing that was different with this user was that in troubleshooting this issue we had set the user up to receive the journalling non delivery reports. I figured that if the emails were not being delivered, maybe sending him the errors would help. However no reports were being received either.  However, according to KB 2829319 this behaviour can be seen. Although I had removed the journal receipient in the web gui, the emails were still not being journalled until I added another external email address to the configuration using the powershell command set-transportconfig -JournalingReportNdrTo [email protected]

At this point, all the email started to be journalled.

Note that we only added the recipient into the mix when I was trying to work on the initial problem so it looks like this wasn’t the only fix.

The other thing we did was change the outboundconnector to be onpremises. Changing the setting in the GUI we then ran Set-OutboundConnector archivemymailconnector -routeAllmessagesviaonpremises $true.

 

These two combinations seemed to fix the issue.

One thing I also learnt was that it is really useful to send multiple emails between changes and keep the subject line starting the same. Use the date/time at the end of the email. That way you can sort the email logs by Subject and just pick out the ones you were working on. By having the subject start with zzz followed by Round X (ie zzz Round 1 – change connector – 1345pm and zzz Round 1 – change connector 1346pm ) then the results are likely to appear at the end of your mail logs if you sort by subject.  Sorting by Date was not always a good idea as mail flow could occur between mail coming into the server and mail leaving the server.

 

Fixed: Installing Powershell 3 fails on Windows7 with “The update is not applicable to your computer”

Powershell 3 was released this week and is now available to download for Windows 7 (sp1) platforms. I tried to install it on my home machine this weekend and got
“The update is not applicable to your computer”. It turns out that this is actually because .net framework 4 (or higher) has not been installed.
The full .net 4 framework package is available at http://www.microsoft.com/en-us/download/details.aspx?id=17718 or you could install the newer 4.5 framework at http://www.microsoft.com/en-us/download/details.aspx?id=30653. Make sure that you close the false powershell installation before attempting the .net installation or the .net will try to install for about 5 minutes on your computer and then complain that another install is already in use and does not give you the option to retry. You can only abort and then run the whole installation again. All in all a pretty bad user experience for trying to install the software.

Thanks to the Troubleshooting guide for the beta version of Powershell 3 that tipped me off for the pre-reqs which are not mentioned on the original download page for Powershell 3 and unfortunately there is no place on that web page to provide feedback.

Retrieve user friendly list of users who have full access to a particular mailbox in Office365

We had a request to provide a list of users who have Full access to a mailbox in Office 365. The get-mailboxpermission is pretty straightforward, but the results show the Windows username as opposed to the descriptive name for the user. The following script should provide the information needed. Note that the first 3 lines connect to Microsoft Online (you will be prompted for username and password) – the last two are the magic ones. Replace “User name” with the users first and last name ie “Andy Helsby” in my case

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

$userlist = Get-Mailbox "user name" | Get-MailboxPermission | Where-Object { ($_.AccessRights -eq "Fullaccess") -and ($_.IsInherited -eq $false) -and -not ($_.User -like "*nt authorityself*") }
$userlist | foreach {get-mailbox $_.user}

If I can work it out, I’ll update the script later to provide a report for all mailboxes – in the meantime this works for 1 mailbox at a time.

Funnily enough, this report didn’t actually help the reason we were asked for the report – that was because the user had issues connecting to someone else’s mailbox. It turns out that the Microsoft Online password had been changed and outlook was using the cached credentials. By removing the stored passwords in the control panel, Outlook prompted for the password and everything started working.

Scripting Guys blog formatting – now in html format.

You can thank me later 😉

On my way home from work late the other night I was listening to episode 152 of the Mind Of Root Podcast where Keith and Steve interviewed Ed Wilson from the Hey Scripting Guy! blog. It was a really interesting podcast and explained their goals to get users learning Powershell and push out some best practice ideas.  So far I like the power of Powershell but I’m finding the learning curve pretty steep. Especially as I can do a lot of my scripting requirements within a normal dos batch file in a lot fewer lines than Powershell requires. However I do understand that Powershell provides a lot more functionality, especially when built into products such as BPOS, exchange etc.

The next weekend I found Ed’s scripting blog, read a few articles, commented on one about using streams.exe to unblock zip files (been there, done that – very frustrating to find out you should unblock a zip file before extracting many thousands of files) and then subscribed to the blog feed.

Unfortunately the blog posts lost all their formatting when reading the rss feed so something that looks nice and clear on the webpage

Hey Scripting Guy! blog showing formatting of blog postlooked horrendous when viewed in Google reader – there are no line breaks, text formatting or anything else that makes the blog post easy to read.

Hey Scripting Guy blog post in Google Reader.I’m not quite sure why the post is a garish pink colour either, but I could live with that.

A quick look through other blogs hosted on blogs.technet.com show that formatting can be preserved (see Matt Hesters Blog feed) below so I sent an email to Ed Wilson to see if the settings could be changed.

imageHe responded back the next day and said he would pass the request onto the webmaster.  Since then I’ve been checking the rss feed and the website and today everything is displaying correctly (it looks like the switch started yesterday).  So thanks to Ed and the Technet website admins – the change is really appreciated. Hopefully this makes the reading of the blog easier for everyone else too!

Fixed: “Server is busy or you’ve lost your internet connection” when changing a BPOS password

Last week I needed to reset a BPOS account password for a new user that I was setting up.  I logged into the BPOS control panel and reset the users password, copied the new one to the clipboard and then proceeded to try and login as the user through the web interface. The web interface took the new password and as expected it then prompted me to change the password as this was the first time of logging on as the user. However on entering a new password I got "server is busy or you’ve lost your internet connection". I obviously haven’t lost my internet connection and I am hoping that the Microsoft servers are not that busy. 

Attempting to login through the single sign on client gave me the following error message – ”Your password could not be changed due since we couldn’t connect to the service. Please check your network connection or contact your service administrator”.

I couldn’t find anything useful online for this issue so I logged a ticket with BPOS support. They came back with a powershell script (below) that fixed the issue and admitted that this is a known problem that sometimes occurs when a password is changed in the gui.

First the BPOS migration tool needs to be downloaded on a machine with powershell installed. Although the migration tools themselves are not required for this particular issue, it provides the extensions to powershell to allow you to manage BPOS. If you are managing BPOS users then you should have this installed already. If not, the migration tools can be downloaded from either  the 32bit migration tool (transporter tool) or the 64bit migration tool pages.

Once installed, from the migration tool powershell prompt, enter the following

    $tcred=Get-Credential
Note: In the Credential Popup Window, type in the Exchange Online Administrator account & password.
Once it is saved, type in the following command.  I’m not sure that this first step is needed as you are prompted for the credentials again when you enter the next line, but as Microsoft said it, it must be true Winking smile

The second command resets the user password –
    Set-MSOnlineUserPassword -identity emailalias@bposemaildomain.com –Password strongpasswordhere -ChangePasswordOnNextLogon $True

 

You will then be able to login as the user with the new password provided above. Note you will be prompted to change the password again, but this time the password change should be accepted.

Enabling powershell to run scripts with registry permissions.

As part of my powershell work I obviously need to run powershell scripts. I tried to run one last night and got the usual message about scripts needing to be signed. I had previously changed the settings on my XP machine, but this was obviously the first time I had run a script on my Windows7 machine.

Running the usual “set-executionpolicy remotesigned” I got the following error message “Execution Policy Change. The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution policy?”

Answering Yes to the prompt I then got the following error message – “Set-ExecutionPolicy : Access to the registry key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell’ is denied”. Sure enough I don’t have permission to this registry key.

I checked with our admin to ensure this wasn’t set in group policy before I started fiddling around. Found out that there is another setting that is user specific that can be set with “Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

After doing this I was then able to run scripts, and more importantly my profile script runs. Seeing as though this is my workstation I don’t really care about anyone else’s powershell scripts on my machine 😉

However, if you want to set it for all users, then set the Scope Parameter to be LocalMachine

To set it domain wide, you need to download the PowerShell group policy templates from Microsoft and follow the instructions to set up a policy.

Security warning pops up when using Outlook2007 and Exchange 2007

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.