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

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.  


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.

The Energized Tech

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 address.

Remember every single user in Office 365 has one.   What will happen then is Outlook see’s the 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.

The Energized Tech

Now we continue forward with leveraging the ability of having Windows PowerShell build out an RTF files without the need for Microsoft Word. 

Just think.  You can NOW generate reports on your server that can be read my Managers and Directors with NO pre-requisite for any software OTHER than Windows PowerShell.

Now one of the things I decided to play with was generating content that’s typically only available in Microsoft Word into a generic RTF file.  Something like a Table.

If you look at the menu in Wordpad / Write you will see NOWHERE an option to “insert table”

Just look.


But we DO know that if you were to generate a simple blank table in Microsoft Word, copy and paste it into Wordpad, it will render just fine as can be seen below with our simple 3x3 table.


Now we just open up this document to find what a SINGLE row looks like.  We’ll use Notepad again but look for the words ‘Patch and Switch’ to see what the formatting looks like for that row.


We will then immediately ‘Permanently Borrow’ that code for out PowerShell script Smile


Now since really this my first crack at doing this, I decided to create an additional function for the columns since they will have multiple values.  (You know as I’m typing this, I’m already thinking of a few ways to redo it too….)

The Write-RTF column function will be in a simliar format.   It will output a Single line each time but accept three or four values (Hint: I cheated and ‘Permanently Borrowed’ the code for Four column output as well)

So as before we’ll have a string which contains the same content as the RTF code from the text file, but we’ll swap out the words like ‘Patch and Switch’, ‘Technet’ and ‘Big Guy’ with actual Powershell variables.

Function Write-RTFColumn
        # Regular Line - 3 column output
        '0' { $output="\trowd\trgaph108\trleft5\trbrdrl\brdrs\brdrw10 \trbrdrt\brdrs\brdrw10 \trbrdrr\brdrs\brdrw10 \trbrdrb\brdrs\brdrw10 \trpaddl108\trpaddr108\trpaddfl3\trpaddfr3
\clbrdrl\brdrw10\brdrs\clbrdrt\brdrw10\brdrs\clbrdrr\brdrw10\brdrs\clbrdrb\brdrw10\brdrs \cellx3121\clbrdrl\brdrw10\brdrs\clbrdrt\brdrw10\brdrs\clbrdrr\brdrw10\brdrs\clbrdrb\brdrw10\brdrs \cellx6238\clbrdrl\brdrw10\brdrs\clbrdrt\brdrw10\brdrs\clbrdrr\brdrw10\brdrs\clbrdrb\brdrw10\brdrs \cellx9355
\pard\intbl\widctlpar\f1\fs22 "+$value1+"\cell "+$value2+"\cell "+$value3+"\cell\row
\pard\sa200\sl276\slmult1\f2\lang9`r`n" }
    Write-RTFDoc $output



If you look you’ll see I’ve highlighted where I’ve put the values in with Bold and Underscore.   If you compare the original code from the RTF file here are the values that were there originally.

\clbrdrl\brdrw10\brdrs\clbrdrt\brdrw10\brdrs\clbrdrr\brdrw10\brdrs\clbrdrb\brdrw10\brdrs \cellx3121\clbrdrl\brdrw10\brdrs\clbrdrt\brdrw10\brdrs\clbrdrr\brdrw10\brdrs\clbrdrb\brdrw10\brdrs \cellx6238\clbrdrl\brdrw10\brdrs\clbrdrt\brdrw10\brdrs\clbrdrr\brdrw10\brdrs\clbrdrb\brdrw10\brdrs \cellx9355
\pard\intbl\widctlpar\f1\lang1033 Technet\f2\lang9\cell\f1\lang1033 Big Guy\f2\lang9\cell\f1\lang1033 Patch and Switch\f2\lang9\cell\row


If you’re like my sample script so you can play for yourself without cutting and scraping screen bits together I’ve uploaded it to the Technet Script Gallery for all to share.  

It’s a pretty simple idea and it’s DEFINITELY something that can be expanded upon (especially in the processes).  

Other ways it could be improved upon would be options to select fonts and Pitch, Bold, Italics or even allowing data to be piped to a function.

Let’s just this “V1”, download and play with it.  At the least you can use it now to get data from a server and build an RTF file directly with it and use “SEND-MailMessage” to email those lovely reports!

Enjoy ! If you have any questions you can ping me anytime.  This was a fun one to pull together.

The Energized Tech