About once a month I get this question in my inbox…    Sometimes it also contains multiple swear words, but I’ll edit that here

“Nick.   I am in the middle of an cut-over migration to Office 365.   My onsite Microsoft Outlook 2013 client keeps connecting back to the in-house Exchange Server even though I have published the autodiscover record for the domain”.

So, the answer is simple but unfortunately it takes sifting through many Technet articles and forum posts to get to it.   Block Outlook from using the SCP lookup method to find the users mailbox….

Option 1.

Download this file and run on your machines running Outlook 2013.

Option 2.

Manually Add to HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\AutoDiscover a DWORD ExcludeScpLookup with a value of 1.

Option 3.

Create a group policy preference for the network to generate the above registry entry on your client systems.

I just found this really good Channel 9 interview with Mark Minasi and Mark Russinovich on Cloud computing.   Well worth a watch if you are into this kind of thing….

Over the past month, we have been working with a customer on migrating to Office 365.   Unlike all our other migrations, this customer had a large amount of Public folders and public folder data in Exchange 2010 onsite. This turned out to be a major stumbling block for NTES and also Microsoft.

Finally today, we are migrated, but the steps NTES and our client took directly with Microsoft Support will mean that you will see some updated TechNet articles very soon on this very subject!   In the meantime, here are the issues and the steps we took to migrate a mass of Public Folders to Office 365.

Patch on up

First, make sure you are running Exchange Server 2010 Service Pack 3

Permissions first It may seem obvious, but make sure you have the right permissions.   Your account you are connecting from must be the owner of all the public folders in Public Folder Management.   Also, the account must be a member of the Organisation Managers Group.

25MB Emails are a no no… Our client uses Public folders to store large emails.   Mainly as this client is a design house these things are not unexpected.  But it will cause you numerous errors during your migration (and it won’t work!).   To get around this issue, you need to run a tool called EXFolders.   Download and run from the Exchange BIN folder, import the registry key and start the application.   Jim Banach has detailed the whole process on his blog which I strongly recommend reading.

Spaces in Aliases (argument in office as to if that rhymes)

Older versions of Microsoft Exchange allowed you to have spaces in the aliases of the subfolders of your Exchange Server Public folder store.   This also mean that the emails for any mail enabled public folder may be corrupted with the space.   Office 365 is built with Exchange 2013, which does not allow spaces.   So you need a script to run on your in house exchange server to fix this.

$pfs = Get-MailPublicFolder | where {$_.alias.contains(‘ ‘)} $pfs | Foreach { Set-mailpublicfolder -Identity $_.Identity -Alias ($_.Alias -replace “\s”)}

The rest is here..

The rest of the (not missing) migration instructions are clearly detailed here

After you have migrated Your users after migration of the data will not have permissions to the public folders.   You have two choices, read this article on assigning specific permissions.   Or, run this in your Office 365 powershell to give everyone access (including new persons).

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false

Special thanks to Mark Costello from Continuum Technologies for documenting all this and allowing me to share!

Well, that was convoluted to say the least!

This link is where you need to go if you are a Microsoft Partner and wish to access your Cloud Benefit credit for Azure.    Its simple because the link is here, but trust me…   it took 1 hour and a chat to the support person for me to find it!

With the recent 1TB upgrade of user personal storage on Microsoft Office 365 you have lots of space to play with… this is a great thing.   However last week I ran into a weird issue where I was uploading about 20 large files (not over the 2GB limit).   All went well, but on just three of the files, I hit this error:

Instead of doing my usual “hit the repair button”,which re-syncs the entire library after taking a local backup, I decided to speak to Microsoft Technical support because I didn’t want just the fix, but also the reason.   It turns out that sometimes Onedrive for Business has a bit of a meltdown with large amounts of large files into the storage online.    The message “The server is out of space.” is not true, but the sync client thinks it to be.

The solution for me was to remove the three files to a normal folder on the PC.   Check that Onedrive for Business reported up to date, then add the files back one by one.     Then the uploaded completed and all is well.

SEE BELOW FOR UPDATES

Original Post 16.10.2014:

________________________________________________________________________________________

Today, I was working with a nice PSS chap in Microsoft (Hi there Om Prakash Nath!)

We were both working on a problem we were having where transport rules in Microsoft Office 365 were not correctly blocking executable attachments within emails to our clients.    This is something of a vital requirement nowadays with the likes of Cryptolocker, and ZIP attachments with SCR scripts and the like.

Bottom line of our problem is that two articles on the web that descibe how this SHOULD work, do not seem to work.   In one case a client literally had all their mail blocked when using one method, attachment or not!

The first article we followed was this:
http://social.technet.microsoft.com/wiki/contents/articles/24715.office-365-block-incoming-attachments-cryptolocker-and-other-email-transit-virus.aspx

The second this:

http://blogs.msdn.com/b/tzink/archive/2014/04/08/blocking-executable-content-in-office-365-for-more-aggressive-anti-malware-protection.aspx

Both ended up with all sorts of strangeness, including not working at all and also blocking EVERYTHING for some customers!   Not cool at all.

I opened a case with Microsoft, and we worked through the problem.    The only sure method we got working correctly was to use Powershell to connect to the tenant and then to run the following command:

REMOVED – SEE BELOW

After about 15 minutes, this worked without fail, including messages that had ZIP attachments with executable content within.

Hope it works for you too!

Update: 18.10.2014

After more testing, I noticed that some executable attachments, including SCR files, in ZIP’s were still getting through even with the below instructions.   I then checked and found that the Office 365 filtering only blocks the following executables, and checks more than just the extension (it checks to see that it is, in fact, an executable).

Below is a list of the extensions that the Office 365 Scanner (as of today) detects with my original command in this post below.

So, that explains why the SCR gets past the scanner.      Its not on the list above…..

To fix this, we are going to need a second rule, and I will shortly post that here in a Powershell command as well!    I promise to be back in 48 hours or so….

Update: 19.10.2014

OK, back as promised.    Man, the documentation sucks for this….

Here are the two commands, which you can enter in powershell (and add extensions as you see fit) in the following order…

This is the rule for blocking attachments that have executable content.

New-TransportRule -Name ‘Rule 2 – Block Executable Content MS Standard’ -Priority ‘0’ -Enabled $true -AttachmentHasExecutableContent $True -RejectMessageReasonText ‘Block Rule 2 – Sorry your mail was blocked because it contained executable content’ -StopRuleProcessing $true -SetAuditSeverity Low -SenderAddressLocation HeaderOrEnvelope

This is the rule for blocking attachments that the extension of the file matches whatever you wish below.   Each extension should be in quotes, and separates with a comma…..

New-TransportRule -Name ‘Rule 1 – Block Attachments Rule – Extensions’ -Priority ‘0’ -Enabled $true -AttachmentExtensionMatchesWords ‘vbs’,’scr’ -RejectMessageReasonText ‘Block Rule 1 – Sorry your mail was blocked because it contained executable content.’ -StopRuleProcessing $true -SetAuditSeverity Low -SenderAddressLocation HeaderOrEnvelope

Lastly

It is important to wait about 60 minutes before you absolutely say to yourself “this didn’t work”.   The Office 365 filters take some time to kick in, remove themself and add themselves!    Give it time, have a cup of coffee and come back and check!

Files

Here is a ZIP file with an EXE in it (Regedit.exe) and here is a ZIP file with a dummy SCR Screensaver file in it, which you can test with from an external account.

Today again I found myself trying to remember the logon commands for Office 365 Powershell!   (Weirdly, I can remember commands once I am in, but constantly forget the logon ones).   Anyway, because this frustrated me again, a bit of Googling found me this blogpost from Ryan Mangan.

Now, the whole story is not on Ryan’s site.    There are some other things you need to do to make his scripts work without constant prompt to run….

1. Make sure you run the command Set-ExecutionPolicy Unrestricted
2. Make sure to run the command  Unblock-File C:\windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1
3. …and this one….  Unblock-File C:\Office365\office365login.ps1

Thanks Ryan!

If you see this kind of craziness when you click the Sync Button in Sharepoint on your Office 365….

It is likely that you upgraded from Wave 14 to Wave 15 (as far as I can tell).     What has happened is that your Sharepoint CSS has got screwed up.   The fix is actually quite an easy one!

Go into site settings, Look and Feel, and change the theme to something else.    Save it, check it, and you should now have everything back to as it should be….

There is no support article for this right now…   but I guess “Crazy icons on your Sharepoint” isn’t a title Microsoft would want on support.microsoft.com

I am a month into using Dropbox at our offices.  The migration wasn’t easy but it has been totally worth it.  No more storage sync issues, no more support calls complaining

I am not the only one that has problems with Onedrive and its confusing mess.  Microsoft, now years into this product development, still havent fixed this and I for one have given up on promoting it for business use for shared files.  Oddly, as a personal storage solution, Onedrive and Onedrive for business seems sound and working to me and clients I work with, but for shared storage its a disaster.

If you search the web, you will find reference to promised updates for Onedrive for Business NGSC and Sharepoint library sync improvements. However, my advice to any business out there right now is that Dropbox for Business, at 10 Euro a month per user, is your best bet if you are going to store files online.

This is a re-posting of a Erin’s IT blogpost

This issue I have been fighting with for a couple of days, thinking that something was actually wrong with the migration.  But it turns out its a cosmetic issue with some Office 365 tenants.  In the downloaded report you will see:

Couldn’t find a request that matches the information provided. Reason: No such request exists in the specified index. –> Couldn’t find a request that matches the information provided. Reason: No such request exists in the specified index.

However, it seems that everything is, in fact, OK…    though I am still working on confirming this for certain with Microsoft.

Erin’s IT original Post

Problem – Running a Microsoft cutover migration fails with following error:

MigrationTransientException: No such request exists in the specified index. –> No such request exists in the specified index.

Mitigation – This issue is just a cosmetic issue in the reporting part, which will be resolved in future releases, in the next 1-2 weeks.

The problem is related to looking at the underlying data move – the Migration service is unable to retrieve it, or manage it in any way (Start, Stop, Remove, Set), so it assumes that it has failed. Even so, the migration of data is working as expected.

You may run, from time to time, the following commands in order to compare the values, in order to ensure that indeed the data is migrated:

Get-MailboxStatistics <mailbox> -debug | fl

Get-MailboxFolderStatistics <mailbox> -IncludeOldestAndNewestItems -IncludeAnalysis -Debug | fl

Expected resolution – June 2016

Cause – Unknown, affects seemingly random tenants.

“There was a general problem while updating the user’s signatures and settings during the operation”

A very generic error message on a client machine running EXSYNC.EXE which other than above appeared to be ok.  The server also was giving no errors, and policy tests worked.

The issue, was simple, but not simple to find.  Because the client machines used to be connected to an internal Exchange server that had been retired, and the mail moved to Office 365, the OWA settings that existed would not work.  By removing the updates on the disclaimer rule to update OWA and Outlook, to just Outlook, this issue went away.

About once a month I get this question in my inbox…    Sometimes it also contains multiple swear words, but I’ll edit that here

“Nick.   I am in the middle of an cut-over migration to Office 365.   My onsite Microsoft Outlook 2013 client keeps connecting back to the in-house Exchange Server even though I have published the autodiscover record for the domain”.

So, the answer is simple but unfortunately it takes sifting through many Technet articles and forum posts to get to it.   Block Outlook from using the SCP lookup method to find the users mailbox….

Option 1.

Download this file and run on your machines running Outlook 2013.

Option 2.

Manually Add to HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\AutoDiscover a DWORD ExcludeScpLookup with a value of 1.

Option 3.

Create a group policy preference for the network to generate the above registry entry on your client systems.

About once a month I get this question in my inbox…    Sometimes it also contains multiple swear words, but I’ll edit that here

“Nick.   I am in the middle of an cut-over migration to Office 365.   My onsite Microsoft Outlook 2013 client keeps connecting back to the in-house Exchange Server even though I have published the autodiscover record for the domain”.

So, the answer is simple but unfortunately it takes sifting through many Technet articles and forum posts to get to it.   Block Outlook from using the SCP lookup method to find the users mailbox….

Option 1.

Download this file and run on your machines running Outlook 2013.

Option 2.

Manually Add to HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\AutoDiscover a DWORD ExcludeScpLookup with a value of 1.

Option 3.

Create a group policy preference for the network to generate the above registry entry on your client systems.

I just found this really good Channel 9 interview with Mark Minasi and Mark Russinovich on Cloud computing.   Well worth a watch if you are into this kind of thing….

Over the past month, we have been working with a customer on migrating to Office 365.   Unlike all our other migrations, this customer had a large amount of Public folders and public folder data in Exchange 2010 onsite. This turned out to be a major stumbling block for NTES and also Microsoft.

Finally today, we are migrated, but the steps NTES and our client took directly with Microsoft Support will mean that you will see some updated TechNet articles very soon on this very subject!   In the meantime, here are the issues and the steps we took to migrate a mass of Public Folders to Office 365.

Patch on up

First, make sure you are running Exchange Server 2010 Service Pack 3

Permissions first It may seem obvious, but make sure you have the right permissions.   Your account you are connecting from must be the owner of all the public folders in Public Folder Management.   Also, the account must be a member of the Organisation Managers Group.

25MB Emails are a no no… Our client uses Public folders to store large emails.   Mainly as this client is a design house these things are not unexpected.  But it will cause you numerous errors during your migration (and it won’t work!).   To get around this issue, you need to run a tool called EXFolders.   Download and run from the Exchange BIN folder, import the registry key and start the application.   Jim Banach has detailed the whole process on his blog which I strongly recommend reading.

Spaces in Aliases (argument in office as to if that rhymes)

Older versions of Microsoft Exchange allowed you to have spaces in the aliases of the subfolders of your Exchange Server Public folder store.   This also mean that the emails for any mail enabled public folder may be corrupted with the space.   Office 365 is built with Exchange 2013, which does not allow spaces.   So you need a script to run on your in house exchange server to fix this.

$pfs = Get-MailPublicFolder | where {$_.alias.contains(‘ ‘)} $pfs | Foreach { Set-mailpublicfolder -Identity $_.Identity -Alias ($_.Alias -replace “\s”)}

The rest is here..

The rest of the (not missing) migration instructions are clearly detailed here

After you have migrated Your users after migration of the data will not have permissions to the public folders.   You have two choices, read this article on assigning specific permissions.   Or, run this in your Office 365 powershell to give everyone access (including new persons).

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false

Special thanks to Mark Costello from Continuum Technologies for documenting all this and allowing me to share!

Well, that was convoluted to say the least!

This link is where you need to go if you are a Microsoft Partner and wish to access your Cloud Benefit credit for Azure.    Its simple because the link is here, but trust me…   it took 1 hour and a chat to the support person for me to find it!

With the recent 1TB upgrade of user personal storage on Microsoft Office 365 you have lots of space to play with… this is a great thing.   However last week I ran into a weird issue where I was uploading about 20 large files (not over the 2GB limit).   All went well, but on just three of the files, I hit this error:

Instead of doing my usual “hit the repair button”,which re-syncs the entire library after taking a local backup, I decided to speak to Microsoft Technical support because I didn’t want just the fix, but also the reason.   It turns out that sometimes Onedrive for Business has a bit of a meltdown with large amounts of large files into the storage online.    The message “The server is out of space.” is not true, but the sync client thinks it to be.

The solution for me was to remove the three files to a normal folder on the PC.   Check that Onedrive for Business reported up to date, then add the files back one by one.     Then the uploaded completed and all is well.

SEE BELOW FOR UPDATES

Original Post 16.10.2014:

________________________________________________________________________________________

Today, I was working with a nice PSS chap in Microsoft (Hi there Om Prakash Nath!)

We were both working on a problem we were having where transport rules in Microsoft Office 365 were not correctly blocking executable attachments within emails to our clients.    This is something of a vital requirement nowadays with the likes of Cryptolocker, and ZIP attachments with SCR scripts and the like.

Bottom line of our problem is that two articles on the web that descibe how this SHOULD work, do not seem to work.   In one case a client literally had all their mail blocked when using one method, attachment or not!

The first article we followed was this:
http://social.technet.microsoft.com/wiki/contents/articles/24715.office-365-block-incoming-attachments-cryptolocker-and-other-email-transit-virus.aspx

The second this:

http://blogs.msdn.com/b/tzink/archive/2014/04/08/blocking-executable-content-in-office-365-for-more-aggressive-anti-malware-protection.aspx

Both ended up with all sorts of strangeness, including not working at all and also blocking EVERYTHING for some customers!   Not cool at all.

I opened a case with Microsoft, and we worked through the problem.    The only sure method we got working correctly was to use Powershell to connect to the tenant and then to run the following command:

REMOVED – SEE BELOW

After about 15 minutes, this worked without fail, including messages that had ZIP attachments with executable content within.

Hope it works for you too!

Update: 18.10.2014

After more testing, I noticed that some executable attachments, including SCR files, in ZIP’s were still getting through even with the below instructions.   I then checked and found that the Office 365 filtering only blocks the following executables, and checks more than just the extension (it checks to see that it is, in fact, an executable).

Below is a list of the extensions that the Office 365 Scanner (as of today) detects with my original command in this post below.

So, that explains why the SCR gets past the scanner.      Its not on the list above…..

To fix this, we are going to need a second rule, and I will shortly post that here in a Powershell command as well!    I promise to be back in 48 hours or so….

Update: 19.10.2014

OK, back as promised.    Man, the documentation sucks for this….

Here are the two commands, which you can enter in powershell (and add extensions as you see fit) in the following order…

This is the rule for blocking attachments that have executable content.

New-TransportRule -Name ‘Rule 2 – Block Executable Content MS Standard’ -Priority ‘0’ -Enabled $true -AttachmentHasExecutableContent $True -RejectMessageReasonText ‘Block Rule 2 – Sorry your mail was blocked because it contained executable content’ -StopRuleProcessing $true -SetAuditSeverity Low -SenderAddressLocation HeaderOrEnvelope

This is the rule for blocking attachments that the extension of the file matches whatever you wish below.   Each extension should be in quotes, and separates with a comma…..

New-TransportRule -Name ‘Rule 1 – Block Attachments Rule – Extensions’ -Priority ‘0’ -Enabled $true -AttachmentExtensionMatchesWords ‘vbs’,’scr’ -RejectMessageReasonText ‘Block Rule 1 – Sorry your mail was blocked because it contained executable content.’ -StopRuleProcessing $true -SetAuditSeverity Low -SenderAddressLocation HeaderOrEnvelope

Lastly

It is important to wait about 60 minutes before you absolutely say to yourself “this didn’t work”.   The Office 365 filters take some time to kick in, remove themself and add themselves!    Give it time, have a cup of coffee and come back and check!

Files

Here is a ZIP file with an EXE in it (Regedit.exe) and here is a ZIP file with a dummy SCR Screensaver file in it, which you can test with from an external account.

Today again I found myself trying to remember the logon commands for Office 365 Powershell!   (Weirdly, I can remember commands once I am in, but constantly forget the logon ones).   Anyway, because this frustrated me again, a bit of Googling found me this blogpost from Ryan Mangan.

Now, the whole story is not on Ryan’s site.    There are some other things you need to do to make his scripts work without constant prompt to run….

1. Make sure you run the command Set-ExecutionPolicy Unrestricted
2. Make sure to run the command  Unblock-File C:\windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1
3. …and this one….  Unblock-File C:\Office365\office365login.ps1

Thanks Ryan!

If you see this kind of craziness when you click the Sync Button in Sharepoint on your Office 365….

It is likely that you upgraded from Wave 14 to Wave 15 (as far as I can tell).     What has happened is that your Sharepoint CSS has got screwed up.   The fix is actually quite an easy one!

Go into site settings, Look and Feel, and change the theme to something else.    Save it, check it, and you should now have everything back to as it should be….

There is no support article for this right now…   but I guess “Crazy icons on your Sharepoint” isn’t a title Microsoft would want on support.microsoft.com