Easily Prepare for Outlook Client for Office 365

When you begin to consider Office 365 you’ll have to look at one key piece in your environment.  Just what version of Outlook are you running right now?

For some you may be licensed for the newest version of Office and will just mark that in as part of the upgrade process.  

But for others that is a project in itself, especially if you’re looking at 500+ systems in your environment.    With that in mind you start to rethink your options.

Office 365 DOES in fact support connections from Outlook 2007 and Outlook 2010.   There are two ways of doing this.

The first is to connect to portal.office.com and download the configuration software from Microsoft which will do all of the dirty work for you.  It’s located under the Office 365 Software section in the “Desktop setup” location.  Just click on the “Set up” button and download this tiny application and run it.

image

 

It looks like this and works very well with a quick but of authentication first…

image

It will then check your system and determine the updates needed for your Outlook version to connect to Office 365

image

This process works great but it requires local administrative rights and must be run on each workstation.  If you do some digging online you can probably find the exact downloads for your environment or, you can do this the easier way.

Why not just let the the Setup application download the files for you and you grab them for later re-use!

Allow the application to download all of the data and then IMMEDIATELY as the first one starts installing access the %LOCALAPPDATA%\TEMP folder and look for files downloaded recently (Sort by Date/Time).

image

Grab the ones most recently downloaded and store them into a little folder called “updates”.  In my example I placed “Updates” on the Root of C:\

image

You’ll probably see one two types of applications in this list either “Windows Installer” or “Application”.  In actual fact they are all the same.

For the applications they are just wrappers containing some MSP files for Office.  To extract them just launch the application from Command prompt with the parameters “/passive” and “/extract:” to extract the contents.   See the example below which extracts the Outlook_2010_32 into the root of the C:\Updates folder.

image

Looking at the picture above there are two new files in our Updates folder.   Repeat this process again with each Application downloaded using the Setup application from Office 365. 

Got them all now?  Here’s the easy part.   You can install the msoidcli_64.msi file with this Commandline.

MSIEXEC.EXE /I”msoidcli_64” /passive /norestart

Then you can also install the patch files (.MSP) with this command line.  We’ll use the recently extracted “outlook-x-none.msp” as an example.

MSIEXEC.EXE /update “outlook-x-none.msp” /passive /norestart

You can pack this into a little USB key, network share as a start for SMBS (No downloading for each workstation which should speed things up!).  You can also in larger environments leverage a deployment solution like System 2012 R2 Configuration Manager to get these updates out to the masses!

Then you can sit home and let the computer do the work for you Smile

Sean
The EnergizedTech

FacebookTwitterGoogle+Share

Office 365 Staged Migrations–Great option for Exchange 2007/2003 !

Often the two migrations I’ll bet people look at at Hybrid for Exchange 2010 and 2013 or A Cutover (for everything else)

The REASON I think Hybrid is looked at more often is simply that if you add in one Exchange 2010 server into your current Exchange 2007 infrastructure, you can reap the benefits of a Hybrid as well.

The cutover is probably quite popular because the technical knowledge required for a cutover is very low.   You literally Export the mailboxes from workstations and Import them back into the cloud.   It’s Time intensive depending upon the size of your data store but the most technically complex part is changing the MX records about.

But there is a 3rd option that sometimes gets ignore that is perfect for Exchange 2003 and Exchange 2007 systems that has very little Risk in it’s setup or implementation, that is the Staged migration.

In the Staged Migration the flow works like this

  • Point Office 365 to your External URL for OWA
  • Give it a list of Mailboxes
  • Sync those mailboxes to Office 365
  • Flip the ID’s from Mailbox on Prem to Mail Enabled
  • Repeat until all mail is done

This scenario requires some permissions and is slightly more technically challeneged than a straight cutover but it offers up some options you may not have realized.

  • Mail from users in Office 365 to on Prem continues to flow back and forth
  • You don’t need to touch the MX records until you absolutely have to
  • Email addresses Migrate up and do not need to be re-created manually

There are some things it does not migrate (like mailbox permissions) but it does allow you to migrate users in blocks and avoids all that nasty “We have to move everybody over this weekend” nonsense.

… The best part?  You can automate 95% of this with Windows PowerShell so you don’t need to stay up all night watching email Import.

Cheers

Sean

The EnergizedTech

FacebookTwitterGoogle+Share

Automate your Authentication for Office 365

Anybody who has worked with Office 365 and PowerShell is probably all too familiar with this prompt.

image

This is your standard popup to ask for a user id and password.  

But if you do this work daily or more importantly you’re trying to schedule this as a task, that little popup can just slow you right down.   So you’ll need some way to stream line that task.

The first way technically works but is a big NO NO from your security friends.   You can encode the ID and password in clear text within a PowerShell script and create the PSCredentials Object needed for the Cmdlets.

 

$UserID=’john@contoso.onmicrosoft.com’

$Password=’NotSoSecretAnymore!’

$SecurePassword=ConvertTo-SecureString –asplaintext –force $Password

$Credential=New-object –typename System.Management.Automation.PSCredential –arguments ($UserId,$Securepassword)

 

This works but as you can see the password is CLEAR as a bell.   From a security standpoint you’re about as naked a somebody streaking a Baseball game.

 

The other option you have which is a BIT better is to store that Secure password as a special text file on a hard drive.   Now I do NOT mean a text file which contains the actual password in Clear Text but more correctly a text file with contains the password in a more obfuscated form.

We can create this file in a simple process

  • Get-Credential for Office365 and store as Object
  • Obtain the Secure Password from the Object and Convert From Secure String
  • Store the converted Secure string as a Text file

This will take all of two lines in PowerShell

 

# Get the credentials through the traditional popup box

$Credentials=Get-Credential

$Credentials.Password | Convertfrom-Securestring | Out-File o365pass.txt

 

You’ll now have a file on the Hard drive which contains the password in an obfuscated form.   You can now read and use this password in the following manner.

$SecurePassword=Get-Content o365pass.txt | ConvertTo-Securestring

Now you can build the credentials from that Password in the same manner as before with the exception of leaving the password in Clear text.

$UserID=’john@contoso.onmicrosoft.com’

$SecurePassword=Get-Content o365pass.txt | ConvertTo-Securestring

$Credential=New-object –typename System.Management.Automation.PSCredential –arguments ($UserId,$Securepassword)

Now understand, this file is still a weak point.   Without much difficulty I can still extract the clear text password.   This file still needs to be stored on a secured folder (possibly even as an encypted file)

But using this same process (once you have the password converted to obfuscated text) we can store this into an encrypted SQL database as a possibility.   We could then manage the credentials in a much more secure manner.

 

However at least now you have some options on how to build those credentials into something you CAN automate, which is one step further than last time.

Sean

The EnergizedTech

FacebookTwitterGoogle+Share

An Easier way to access your Office 365 Cmdlets for Exchange

People that are really big and into Windows PowerShell know all about Implicit Remoting.    It’s a way to access Cmdlets from a Remote server and use them as if they are local.

For those of you just learning PowerShell, I’ll show you something to make that process a LITTLE bit smoother and easier.

 

When you are managing Exchange in Office 365 you normally end up using a process that contains these lines.

 

$Credentials=Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Credentials -Authentication Basic -AllowRedirection
Import-PSSession $Session

 

This process will popup a box on your screen prompting for your credentials, think about it for a bit and then eventually give you access to the Cmdlets.   But we can streamline this.   First let’s note something.  Every single time you execute the Import-PSSession it’s going to download those Cmdlets and spin up a temporary copy.    

If you would like a “cached” copy to make your life easier change this line

 

Import-PSSession $Session

 

To read as this line

 

Export-PSSession $Session –outputmodule o365

 

This will take about the same amount of time as the first run but it will create a locally cached module containing all of those redirected Cmdlets

 

Now that you’ve done this, when you have to Manage the Exchange component of your Office 365 environment you can run this Cmdlet.

 

Import-Module o365

 

Running a Cmdlet will prompt with the credentials used to create the module.     If you’d like to make this more portable, just go in the PSM1 file located under the O365 folder created by the module.   By default this will probably be sitting under the Windows PowerShell folder within Documents under your profile.  

If you’d like the path to it programmatically in Windows PowerShell that should be.

 

“$HOME\Documents\WindowsPowerShell\Modules”

 

Open up the file callled “o365.psm1” in your favorite text editor

 

image

 

Just do a search for the userid in this file

image

and change it with a blank or even a generic one for technicians to replace with.   It can even be words as it’s just part of a popup box for credentials

image

Just save this file.   You can now take that O365 folder structure, zip it up and distribute it to those that need to Manage Office 365 users.     You should also find it’s a bit faster on startup since you don’t need to re-load the Cmdlets from the cloud each and every time.

 

Occasionally Microsoft may update the Cmdlets on the Exchange side and you might have to redo this process but as you can see all of this is a scriptable and automatable process.  You can rebuild the module at any time.

FacebookTwitterGoogle+Share

Windows 8.1 x64 and MSDN–Getting the File Transfer Manager to work

This drove me bananas.   I have MSDN and each every time in Windows 8.1 that I wanted to get myself a download it would only do a Direct download.

This meant that if I started to download something and if it timed out I would have to start all over again.  Which generally is a complete waste of time. 

But MSDN has always had (and still HAS to this day) the File Transfer Manager to allow the ability to download and pause / continue those downloads.    It just doesn’t work in Windows 8.1 64bit version by default. The reason is two fold.

File Transfer Manager is a 32bit (x86 application)

It does not get launched by default in IE 11.  (Still hoping somebody will fix this)

The workaround is simple.

First you need to actually download and install the File Transfer Manager from HERE as the popup to install it does not seem to work on current versions of Internet Explorer.

If you’re trying to launch a download from MSDN and need the File Transfer Manager application to assist you, you must launch this in a 32bit Version of Internet Explorer 11 (Which is still supplied in Windows 8.1). 

You must ALSO send it from the Browser while running in IE9 mode.

To do this here are the steps.

First launch Internet Explorer 32bit version by Navigating to

c:\Program Files (x86)\Internet Explorer\iexplore.exe

If you like you can create a shortcut on your Desktop naming it (IE x86) to make this easier in the long term.

Then login to www.msdn.com

Once there hit F12 in the Browser which will give you the Developer options in Internet Explorer.    Change the “Document mode” to 9 (For Internet Explorer 9 rendering mode) and the “User Agent String” to “Internet Explorer 9″ which will identify the browser as Internet Explorer 9.

Once you have done this you can download from MSDN and it will leverage the File Transfer Manager for your download.  

image

Make sure as well you click on the link under “General” and “Options” to “Place application shortcut on the desktop” to allow you to re-launch the File Transfer Manager later to resume those downloads.

I have just tested and confirmed this ALSO works in the current January release of Windows 10 Technical Preview x64 as the root cause is the same.   MSDN’s File Transfer Manager ActiveX does not Recognize anything higher than IE9 and will not launch within an x64 Internet Explorer.

Sean
The Energized Tech

FacebookTwitterGoogle+Share

Mitigating Risk during Office 365 Staged Migrations

There are really only three scenarios for an Office 365 Migration.   Only three (3)

  • Cutover
  • Staged
  • Hybrid

In the Cutover scenario you literally export all of the email and content on side a) (Exchange any version) and Import all of the email to side b) (Office 365).   Flip your MX records about and go.   Risk to this scenario is dependent upon the Window of DNS cutover time as you may have mail flowing to the old environment or your STOP mail flow period.  (I avoid this concept like a Star Trek fan avoids trying to explain the reason the Klingons looked different in the 60’s version vs the modern Klingons)

In the Hybrid scenario you are running an Exchange 2010 or Exchange 2013 environment, and a mailbox/trust is established with Office 365 and you can migrate up or down as you choose with mail flowing seamlessly.   If you have this setup, this is very nice with minimal risk since you can move test mailboxes up, verify connectivity and determine what needs to happen.

Then there is the Staged migration scenario only available and supported for Exchange 2003 and 2007 servers.   This takes a LITTLE bit of technical knowhow to setup (not a lot) but offers up and interesting alternative to the cutover.   It offers up a VERY low Risk migration if you can’t do a Hybrid configuration.

In this configuration Office 365 connects via Outlook Web Access from the On Prem environment and does an initial mirror of the entire mailbox.  It then establishes SMTP forwarding of inbound emails to the destination Office 365 mailbox to ensure emails sent to the old address forward to the new.

I’ve seen references online which state “After Migration is complete, you disable the Exchange mailbox, flip the user to Mail-enabled, then reconfig them to Office 365”

This is all well and fine but imagine a larger migration that takes over a week? 

Users that are in Office 365 can not communicate with users that are on premise (although they can receive).   Also what about your rollback strategy? 

I prefer not to break or change anything drastically in the old environment until I am 100% satisfied all is good.   More importantly if there is ANYTHING that is a deal breaker that we didn’t plan for, I need to be able to say with 100% conviction “All of your data from Exchange will be there Monday if something bad happens.”

Normally the configuration of Outlook for Office 365 is simple. 

  • Start Outlook
  • Outlook checks to see if this email is part of Exchange
  • Failing that it checks DNS to see if there is an Autodiscover record for it
  • It gets the info from Autodiscover
  • you get prompted for an ID and password for Office 365
  • It’s configured and AWAY YOU GO!

But if you’re in the “partially staged” setup and you need to configure some with Office 365 but can’t use their regular email address the answer is simple.   Set the Email address in Active Directory with the value of their onmicrosoft.com address.

Remember every single user in Office 365 has one.   What will happen then is Outlook see’s the onmicrosoft.com address, immediately gets the configuration for Office 365.  The user experience is still the same, login with your regular email address and your password.   All gets configured and working.

This provides you with an interesting option.  If the user NEEDS to communicate BACK to on-prem users, for that migration period they can still use the old Outlook Web Access to do so.

It also means for a “rollback” (which may not need to happen but you always play “What if) that nothing has actually been deleted.

There are other things to plan for I may talk about later, but the fact you can have BOTH mailboxes accesible DURING a staged Migration is pretty damned cool.

Also note that during your Staged Migration although MAIL will flow to the other side, changes to the local Calendar,Contacts,Notes and Tasks will not.   So if you have to rollback you must remember to export/import that data back.

Sean
The Energized Tech

FacebookTwitterGoogle+Share

Mitigating Risk during Office 365 Staged Migrations

There are really only three scenarios for an Office 365 Migration.   Only three (3)

  • Cutover
  • Staged
  • Hybrid

In the Cutover scenario you literally export all of the email and content on side a) (Exchange any version) and Import all of the email to side b) (Office 365).   Flip your MX records about and go.   Risk to this scenario is dependent upon the Window of DNS cutover time as you may have mail flowing to the old environment or your STOP mail flow period.  (I avoid this concept like a Star Trek fan avoids trying to explain the reason the Klingons looked different in the 60’s version vs the modern Klingons)

In the Hybrid scenario you are running an Exchange 2010 or Exchange 2013 environment, and a mailbox/trust is established with Office 365 and you can migrate up or down as you choose with mail flowing seamlessly.   If you have this setup, this is very nice with minimal risk since you can move test mailboxes up, verify connectivity and determine what needs to happen.

Then there is the Staged migration scenario only available and supported for Exchange 2003 and 2007 servers.   This takes a LITTLE bit of technical knowhow to setup (not a lot) but offers up and interesting alternative to the cutover.   It offers up a VERY low Risk migration if you can’t do a Hybrid configuration.

In this configuration Office 365 connects via Outlook Web Access from the On Prem environment and does an initial mirror of the entire mailbox.  It then establishes SMTP forwarding of inbound emails to the destination Office 365 mailbox to ensure emails sent to the old address forward to the new.

I’ve seen references online which state “After Migration is complete, you disable the Exchange mailbox, flip the user to Mail-enabled, then reconfig them to Office 365”

This is all well and fine but imagine a larger migration that takes over a week? 

Users that are in Office 365 can not communicate with users that are on premise (although they can receive).   Also what about your rollback strategy? 

I prefer not to break or change anything drastically in the old environment until I am 100% satisfied all is good.   More importantly if there is ANYTHING that is a deal breaker that we didn’t plan for, I need to be able to say with 100% conviction “All of your data from Exchange will be there Monday if something bad happens.”

Normally the configuration of Outlook for Office 365 is simple. 

  • Start Outlook
  • Outlook checks to see if this email is part of Exchange
  • Failing that it checks DNS to see if there is an Autodiscover record for it
  • It gets the info from Autodiscover
  • you get prompted for an ID and password for Office 365
  • It’s configured and AWAY YOU GO!

But if you’re in the “partially staged” setup and you need to configure some with Office 365 but can’t use their regular email address the answer is simple.   Set the Email address in Active Directory with the value of their onmicrosoft.com address.

Remember every single user in Office 365 has one.   What will happen then is Outlook see’s the onmicrosoft.com address, immediately gets the configuration for Office 365.  The user experience is still the same, login with your regular email address and your password.   All gets configured and working.

This provides you with an interesting option.  If the user NEEDS to communicate BACK to on-prem users, for that migration period they can still use the old Outlook Web Access to do so.

It also means for a “rollback” (which may not need to happen but you always play “What if) that nothing has actually been deleted.

There are other things to plan for I may talk about later, but the fact you can have BOTH mailboxes accesible DURING a staged Migration is pretty damned cool.

Also note that during your Staged Migration although MAIL will flow to the other side, changes to the local Calendar,Contacts,Notes and Tasks will not.   So if you have to rollback you must remember to export/import that data back.

Sean
The Energized Tech

FacebookTwitterGoogle+Share