Thursday, January 24, 2013

Office365 Shell Commands (for reference)

As of 3/5/13, here are the commands I have used for adjusting Office365.  Generally, I run a PowerShell script the enters all the commands for me once I log in.  I describe the process for setting up and using the PowerShell script here:

From there, I can run any of these commands

remove password expiration:
Get-MsolUser | Set-MsolUser –PasswordNeverExpires $True

remove password complexity requirements:
Get-MsolUser | Set-MsolUser -StrongPasswordRequired $false
(of note - you can only set non-complex passwords via shell, not in the web interface, the web interface will still require complex passwords.  And all passwords, even in the shell, must be 8 characters long)

set user password in the shell:
Set-MsolUserPassword -UserPrincipalName  -NewPassword "orange42" -ForceChangePassword $false

give Bob full access to Joe's mailbox:
Add-MailboxPermission -identity -user -AccessRights FullAccess

remove Bob's full access to Joe's mailbox:
Remove-MailboxPermission -Identity -User -AccessRights FullAccess

give Bob send as access to Joe's mailbox:
Add-RecipientPermission -AccessRights SendAs -Trustee -Confirm:$false

forward Joe's email to Bob (oddly, for the mailbox to be forwarded, you enter the mailbox name and enter the address for where you're forwarding):
Set-Mailbox -Identity joe.smith -DeliverToMailboxAndForward $true -ForwardingSMTPAddress

check forwarding status of a Joe's mailbox:
Get-Mailbox jos.smith| Ft ForwardingSMTPAddress

cancel forwarding of Joe's email
Set-Mailbox -Identity joe.smith -DeliverToMailboxAndForward $false -ForwardingSMTPAddress $null

give Bob.Jones publishing editor permission to Joe.Smith's calendar (in this command, you use usernames and not full email addresses):
Add-MailboxFolderPermission -Identity “Joe.Smith:\Calendar” -AccessRights PublishingEditor -User Bob.Jones

give Bob.Jones publishing editor permission to Joe.Smith's contacts (in this command, you use usernames and not full email addresses):
Add-MailboxFolderPermission -Identity “Joe.Smith:\Contacts” -AccessRights PublishingEditor -User Bob.Jones

In the two commands above, possible permissions are: Owner, PublishingEditor, Editor, PublishingAuthor, Author, NonEditingAuthor, Reviewer, Contributor, AvailabilityOnly, LimitedDetails

Monday, January 21, 2013

Office365 Staged Migration Thoughts

This weekend I did a staged migration from an SBS 2008 server to Office365.  I followed this article for the most part, which was excellent:

In my case, I had the $4 per month Exchange Online plan, which does do active directory sycning as opposed to the small business plan, which does not.

In my case, I had 77 mailboxes I wanted to migrate, some as small as 50 MB, a couple that were 6+ GB and about a dozen that were 3+ GB.  

The things I'd like to remember for future migrations are:
1) really spend time archiving (either just for this process or overall) to get mailboxes as small as possible.  Over time, mailboxes seemed to transfer at a rate of 5 MB per minute - whether I was migrating 3 mailboxes at a time or 10 at a time, so this seemed to be the max upload rate over time (over my 10 Mbps symmetrical circuit).
2) Migrate as many possible mailboxes at a time as the math allows.  In the migration process, Microsoft recommends only doing 3 mailboxes simultaneously.  I don't know where that number (3) comes from.  The process tells you the speed of you upload as you do it, which seemed to average 5 MB/min per mailbox for me.  So I'd recommend figuring out the maximum amount of bandwidth you'd like to use for the process.  Let's say you have 4 Mbps for this process (or 4000 Kbps).  Take that number in Kbps and divide by 666.  That's how many mailboxes the bandwidth will allow.  So in this case, you could do 6 mailboxes simultaneously.
3) When you start a batch, all the users in that batch start forwarding to the Office365 mailbox even though their actual migration has started.  Let's say there are 30 users in your batch and you migrate 8 users concurrently.  If your first 8 users are migrating, those last 22 will already be set to forward their mail to Office365.  Just something to keep in mind.
4) use as few batches as possible.  I had told my users that "you'll be migrated from approximately 3 pm to 6 pm" and then put users in appropriate batches.  While it looked nice to the user to give them exact timelines, making many batches is not efficient because only one batch at a time can run.  Let's say you've got a batch with 10 users and 9 users with 1 GB mailboxes and 1 user with a 6 GB mailbox, that last mailbox will hold up the entire batch from finishing.  Making the batches as large as possible allows for the process to be as dynamic as possible.
5) Don't run the PowerShell scrips to convert on-premise mailboxes to mail user objects until the migration process is complete for the mailbox.  In step 5 of the above article, you can run some PowerShell scripts that will enable autodiscover to reroute to Office365 for migrated mailboxes even though your main autodiscover still points to your on-premise mailbox.  This allows you to migrate a subset of your users (where autodiscover points to on-premise for some and Office365 for others).  In my case, I told my staff that I'd be done Sunday at 6 pm.  I had 8 users who were still mid-migration Sunday at 6 pm.  I ran the PowerShell scripts on those users under the assumption that the migration process would continue afterwards.  This is not true.  The on-premise users no longer have a mailbox so the migration process will break.  I'm going to open up the users's old OST file, export to PST and then import to their new mailbox and not import duplicates in order to fix that since only a subset of data was uploaded.
6) Check email addresses after migration.  Some of my users were sending out email as after the migration.  For some reason, 3/4 of my users had the correct email address set for them in my on-premise AD in the mail user objects, but the other 1/4 had a default reply address that included  This should be checked by going to Recipient Configuration -> Mail Contact in the on-premise mail server.  I didn't see where to set this globally, so I fixed this manually for my misconfigured users.
7) Public folders don't exist on Office365.  Assuming you have shared calendars or contact lists, you can create users that will serve that function.
8) Be prepared for the saturation of your connection when downloading all data for the first time.  The first day after the upload (after a weekend upload), I started configuring user Outlooks as they arrived.  My 10 Mbps downstream bandwidth weas fully utilized all day which led to awful behavior.  The larger OSTs never fully downloaded all their data by day's end and inboxes were updating very slowly.  I got many complaints of "I haven't received an email in over an hour" since the Outlook was downloading data and not updating the inbox.  I had users use webmail on day 1.  Overall, for my network, I had users leave their computers on with Outlook open overnight and overall my connection was completely saturated from 8:30 am to midnight (15.5 hours).  

Sunday, January 13, 2013

Installing .net 3.5 on Server 2012 - error '“Do you want to specify an alternate source path? One or more installation selections are missing source files…”

I was installing DirSync on a Server 2012 server (in the process of doing a staged migration to Office365 from an SBS 2008 machine) and DirSync required .net 3.5.  It should be easy, but when using Server Manager to install the feature, I got this error:

Do you want to specify an alternate source path? One or more installation selections are missing source files…

I followed these excellent instructions to install it:

In my case, I downloaded the ISO file and unzipped just the sources folder and modified the path.

Friday, January 4, 2013

H202 error on Quickbooks caused by DNS/network settings mismatch

This problem caused me hours and hours of headache.

I wanted to move my Quickbooks Pro 2010 database host from one server to another.  I had done everything right on the new host as far as I could tell:

  1. install the database only option on the new server
  2. update the Quickbooks version on the server to the most recent version (R16 as of the installation time)
  3. open up the necessary ports in the firewall (8019, 55338)
  4. share out a folder with the appropriate sharing and file/folder permissions
  5. Open the quickbooks database server manager and scan the appropriate folder were QBW files are stored

In this case, I was getting H202 folders over and over again no matter what I did.  I went through many wrong paths, but I eventually found the problem to be the static IP address I had set.  Even though every network setting matched the settings that DHCP provided to workstations, it still did not work.

The only change I made to get Quickbooks hosting to work was give this new server (a Win 2008 32 bit server) a DHCP reservation instead of a static IP address.  I don't know if this added A record entry in my SBS 2008 server that was required or there was some other property (no WINS on my network) - but that was the sole change I made.

As for what I was seeing (in case this helps others).

This is what I'd get in the ND file when running the QB database server manager (without opening the files - note that engine name ends in _18 even though I'm on QB 2010 which means it should end in _20 . . . this is normal):

FilePath=E:\quickbooks\Test Company.QBW

This is what the ND file would change to when I had static DNS in place:

FilePath=\\\quickbooks\Test Company.QBW

This is what the ND file changed to after being successfully opened once I had the DHCP reservation in place: