Technology, Infrastructure and Cloud Focused.

Father of 3 lovely children, geek, infrastructure expert, technical architect and all round technologist.

BLOG SERIES – MY EXPERIENCE WITH THE FIRST MIMECAST IMPLEMENTATION PART 2

So in this series I wanted to document my journey and experience with setting up (or migrating) a Mimecast Unified Messaging Platform.  Part 1 gave an introduction into what Mimecast offered, the benefits of their cloud solution and the superb service you get guiding you though this process.

Although this guide deals with the configuration and interaction with Office 365 (where our hosted Exchange environment is located) the process is similar to an Enterprise wide deployment.  A useful tip here could be to setup a test Domain, add this to your existing email environment and just test the process on this test domain for a reduced risk migration.

I am wrapping up 2 stages within the Mimecast process here (Stage 2 – Account configuration and Stage 3 – Outbound Routing), but the summary of this is below:

Step 1 (Admin users):

Mimecast Login Pahe

Mimecast Login Screen


After you receive your “Super Administrator” (this is the account that has full access to every feature within the Mimecast Admin console) details from Mimecast it is recommended to first setup a series of users with the access you require. 

  1. Log into your Mimecast portal and first review the default roles.
  2. Next Click on the “Roles” tab to display the built-in roles.
  3. Roles are predefined permission levels that Mimecast has provisioned – you can create your own but for this example we have setup another Super Admin.
  4. To select a role just click on that with the mouse, here you select the “Add user to role” function and select your required user.

    Mimecast Default Roles

    Mimecast Roles

  5. If the user is not listed you may need to manually add the user to your console – Directories – Internal – Click Domain Name and select “New Address”.
  6. Test you can login within the newly created account.
  7. Next have a play with setting up with a dummy or test user account and move them into the different roles.  Later on down the line we will be looking at giving our Service Desk login rights to track messages etc..

Step 2 (Configure Routing):

Next comes the interesting phase, here we are going to ensure that all our emails leaving our organisation are routed into the Mimecast cloud.  In our example our message flow is detailed below (sorry did not have the time to do this in Visio so used my friend – Cacoo):

Check our mimecast network diagram

Office 365 and Mimecast diagram

Last year we decided to move our Exchange 2007 servers over to Office 365 instead of carrying out an upgraded.  We only have around 10 users so this makes perfect since, therefore these steps are designed for Office 365 environments, although similar if you host on-premise (just remove and adapt where needed):

  1. Ensure ALL your domains are registered with Mimecast before proceeding, if you have any issues then please contact Mimecast Support.
  2. Add the Mimecast MX records into your DNS zone at the highest priority (i.e. if you records are currently set to a preference of 10, then select the Mimecast preference to 100) – this will allow time for the records propagate and then help in the next few steps.
  3. If you use SPF records then ensure the following is setup (of course these may change so check with Mimecast support, however these are correct as of this post):  v=spf1 ip4:135.196.24.192/28 ip4:213.235.63.64/26 ip4:94.185.240.0/24 ip4:212.2.3.128/26 ip4:94.185.244.0/24 ip4:195.130.217.0/24 ip4:91.220.42.0/24 ~all
  4. Configure an Outbound connector in conjunction with the Mimecast KB article – http://www.mimecast.com/mc/kb/Mimecast/KBID10601.htm
  5. Notify Mimecast for them to monitor the outbound emails – these are used for Mimecast to configure a “TO” whitelist.
  6. Thats it….!!! – See so simple…
  7. I would recommend keeping this in place for 2 weeks.
Stay tuned for part 3.

 

Small Business Server 2008 Backup failure

Just recently I have had to carry out a bare metal restore on my Small Business Server 2008 setup in my home lab.  I had to migrate my email over to Microsoft’s BPOS offering to ensure I could still gain email access for the family.

Now after finally restoring the system from my Windows Home Server (v1) backups as the built in SBS backups failed miserably with BSoD’s and failed booting.

Having now restoring the server I have been presented with this error – Creation of the shared protection point timed out. Unknown error (0x81000101)

Or a screenshot below:

Imageof sbs backup failure

Well I have tried the hotfix from Microsoft – http://support.microsoft.com/kb/956136 but got the error that this hotfix was not applicable to this Operating System.  I assume this is either to do with Windows 2008 Service Pack 2 being installed or due to the fact that this is a Window Vista hotfix.

I am re-running a manually backup to see if this has any effect.

When venter 4.1.0 fails to startup after install

Hello all, before I start ranting about my problems over the weekend trying to recover my Microsoft Small Business Server 2008 and Active Directory, I will tell you about a small problem with my vCenter installation.

If (like me) you know about VMWare but a newbie to vCenter you may not know why after you restart your vCenter server why you cannot connect to vCenter with the VSphere client. After some digging around in the VMWare fourms I came across this post:-

http://communities.vmware.com/thread/89855;jsessionid=20C841686151B792D2561F3587950AAC

Which explains the problem as vCenter services trying to start before your SQL server / service instance starts (or in my case SQL Express). So a quick fix would be to go into Services and change the dependency of the service, otherwise follow these instructions as per my screenshot:-

Click start – run, then type in regedit

Click enter

Navigate to

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesvpxd

Name: DependOnService (REG_MULTI_SZ)

Value:

ProtectedStorage

lanmanworkstation

Check your SQL service instance name within the services.msc console, default and on my server it was the below. then add this into the Reg key, click OK, close regedit and reboot the service

MSSQL$SQLEXP_VIM

A screenshot below shows the relevant information:

Vcentre image