Thursday, 21 May 2015

Automating the creation of mail enabled Security Groups for a Cutover Migration


One of the benefits of performing a native Cutover migration is that distribution groups are created and memberships nested during the migration batch. Unfortunately Security Groups are not created automatically during a Cutover migration, however if they exist during the Cutover migration they will be populated and assigned their correct address, so we must pre-stage them prior to the mailbox moves.

To pre-stage them we need to have a matching Name, DisplayName and Alias. We should also assign an email address as they will be mail enabled. During the Cutover migration the correct addresses will be assigned, so we can simply provide an @tenant.onmicrosoft.com address during the pre-stage process.

So can we automate this? Creating them manually isn't much of an issue for relatively few, but when there are a lot some automation is appreciated and makes your job far easier.


So let's take a look.

First of all let's take a look at the Security Groups.

Get-DistributionGroup |where{$_.recipienttype –like "*security*"}

Once happy, we can export them to CSV, taking the attributes we need for an import into Office 365.

Get-DistributionGroup |where{$_.recipienttype –like "*security*"} |Select Name,DisplayName,Alias,WindowsEmailAddress



We don't actually need the Windows email address, but we can use the outputted CSV to check the default address after we have automated their import into Office365 and the Cutover migration has assigned the correct addresses.


So let's take a look at the CSV data – check it and ensure it is correct and the Name, DisplayName and Alias fields are populated:



When we are ready to import the Security Groups into Exchange Online, open a remote Powershell session to your tenant.

Once in, we need to import the CSV file and map the New-DistributionGroup creation to map the Name,DisplayName and Alias fields and also assign an @tenant.onmicrosoft.com address.

So how do we do this?

Import-Csv "csv location" |ForEach { $alias = $_.Alias; $primary = "$alias@c3365labs.onmicrosoft.com"; New-DistributionGroup -Name $_.Name -DisplayName $_.DisplayName -Alias $_.Alias -Type Security -primarysmtpaddress $primary}

We take the CSV and import it.
We create a For Each statement to loop through the CSV
We add some Variables to assign the alias name (it will have no spaces so is ideal) to the tenant email address.
We then utilize the New-DistributionGroup cmdlet and use variables to populate the Name, DisplayName and Alias' from the CSV and assign the aforementioned @tenant.onmicrosoft.com address.

Depending on how many mail enabled Security Groups you are importing this may take some time. But once completed you will see they have been created:



That's all for now.

Take care,

Oliver Moazzezi – MVP Exchange Server
Twitter: @OliverMoazzezi

Friday, 15 May 2015

Auditing and converting Shared Mailboxes after a Cutover, Staged or Third Party migration


Moving mailboxes to Office 365 is a painless experience, providing of course it has been planned carefully. Unless you move mailboxes using Exchange Hybrid you will need to convert your shared mailboxes back to a shared mailbox once they have been moved however. This is the case for Cutover, Staged or using some third party tools like MigrationWiz.
 
 
So let's look how we would normally convert one mailbox manually.
 
1. Once the mailboxes have moved, logon to the tenant and in the Exchange Admin Center, select the mailbox. On the right hand side you will have 'convert to shared mailbox'



 
2. Selecting this brings up the following warning, select Yes

3. And that's it - the mailbox is now a shared mailbox:


 
 
 
So that's great if you only have one, or a select few shared mailboxes that makes the task of doing this for each one manually a very short, if somewhat mundane affair.
 
 
So what happens if you have a lot?
 
Well you can do it manually like in the scenario above, or we can automate it.
 
In this case we can audit them in preparation for any move to Office 365.
 
 
1. Get a list of all shared mailboxes from on premise Exchange Management Shell session

Get-Mailbox –resultsize unlimited –recipienttypedetails sharedmailbox |Select userprinciplename |Export-CSV






 
2. This will provide an output like the following. Check the CSV is formatted correctly and clean it up if necessary




Finally, after you have moved the mailboxes, with your Exchange Online PS Session, run the following command:

Import-Csv "csv file" |ForEach { Set-Mailbox –Identity $_.UserPrincipalName –Type shared }



Running Get-Mailbox –Type Shared should then show all required mailboxes have been converted to shared mailboxes.
 
We can continue to run this command with the full CSV even if not all the shared mailboxes have been moved over, you will simply get an error for the ones that haven't been moved yet, and a yellow informational alert for the ones that already have and thus are already of the type: shared.
 
 
In this scenario the mailboxes should not have been licensed, so there's no need to remove any licensing from them as you will still be in the grace period – as Shared Mailboxes do not require a license in Office 365. If for some reason you are facing a scenario where they are, I will post up next week how to clean this up with a remote powershell session to Azure AD for a more automated removal of any assigned license.
 
Take care,
 
 
Oliver Moazzezi – MVP Exchange Server
Twitter: @OliverMoazzezi
 

Tuesday, 5 May 2015

Microsoft Ignite - announcing "Office 365 for Exchange Professionals"

I have had the great pleasure these past few months of reviewing a new eBook that is launching this week, called "Office 365 for Exchange Professionals".

The book has been written by Tony Redmond, Paul Cunningham and Micheal Van Horenbeeck which provides fantastic deep technical knowledge and real world scenarios for Exchange Admins looking to move, or indeed, already managing Exchange Online in Office 365.

The book covers a myriad of scenarios including:

When and how to use Cutover, Staged and Hybrid migrations – and talks about potential pitfalls and benefits of third party migration tools

How the Office 365 architecture and infrastructure has evolved from Live@Edu and BPOS into the Azure aligned cloud platform it is today

How to synchronise your on premise users to the Cloud using Directory Synchronisation and achieve single sign on with Active Directory Federation Services

Managing objects in the Cloud like mailboxes, distribution groups and activating Exchange Online features for your business and users

How to utilise eDiscovery, retention and Information Rights management policies and manage auditing in your Office 365 deployment

And many more.

The eBook provides real world insight to your Office 365 deployment or migration and will impress upon you the best approach and practices for any Office 365 transition – something many current books simply lack with their black and white approaches to 365 management; designed to give you just enough knowledge to pass an MCP exam.


The book is being launched at Microsoft Ignite, please grab your copy there or add this link to your favourites to await more information on its release:


Take care,

Oliver Moazzezi - MVP Exchange Server

Cloud Solution Provider Program Multi Channel capability is coming!

Microsoft will be releasing multi channel capability on (or close to) Wednesday May 6th!

Here's a snippet from non NDA release notes from Microsoft released on Friday to all CSP partners and Microsoft Partners.




"I’m excited to share that Multi-Channel capability is coming to the Cloud Solution Provider (CSP) program, on track for release on or close to Wednesday, May 6th.   Multi-Channel provides CSP partners like you the ability to provision CSP subscriptions for customers that already have an existing tenant with existing subscriptions purchased through other Microsoft Channels (e.g., Direct, Open, Advisor, etc). In short, CSP subscriptions can co-exist with other subscriptions on the same tenant.

Multi-Channel capability has been one of the most requested features that our CSP partner community has asked for to help enable new Office 365 sales opportunities through CSP. Prior to enabling Multi-Channel, it was only possible for you, as a CSP partner, to order subscriptions for customers that you provisioned as a CSP Partner on a separate tenant. However, it’s common to work with customers who have an existing tenant and in these cases you need the ability to provision CSP subscriptions for these customers on their existing tenant. Multi-channel capability makes this possible.

A comprehensive overview of Multi-Channel capabilities is provided in the attached walk-through deck and FAQ document.  I encourage you to review both files and contact me if you have any questions. Briefly, Multi-Channel:

·         Enables CSP partners to provision CSP subscriptions for a customer that has an existing tenant
·         Enables CSP subscriptions to co-exist with other subscriptions on the same tenant (e.g. purchased directly from Microsoft, via Open, EA)
·         Allows your customer to retain full control over their existing subscriptions

It’s important to note that Multi-Channel does NOT provide the capability to transition existing subscriptions over to CSP subscriptions. All of the customer’s previously provisioned subscriptions remain, the customer maintains control over those subscriptions and the terms of those existing subscriptions are not changed in any way. Additionally, Multi-Channel does NOT enable multiple CSP partners to sell to the same customer. There can only be one CSP Partner associated with a single customer. “Multiple-CSP Partners”  is a separate capability which is included in the CSP roadmap for release in CY15/Q3".


Being able to now split purchasing between different vendors provides an exciting opportunity to Office 365 customers as long as Microsoft removes any confusion of having different pieces of 365 from different suppliers.


Have a great week!

Take care,

Oliver Moazzezi - MVP Exchange Server





Thursday, 19 March 2015

Configuring Exchange 2013 for use with the SetRoutingOverride method and Transport Agents


The SetRoutingOverride method was first introduced in Exchange Server 2007 as a supported method for using within Transport Agents. Transport Agents were previously known in prior versions of Exchange, notably Exchange 2000 and Exchange 2003, as SMTP Event Sinks. Although prior to Exchange 2007 we could natively choose different outbound routing using SMTP connectors and deny permissions if we wanted to - however it was a pain to setup and required a registry key to be set for Deliver Restrictions to work.
 
The SetRoutingOverride method was introduced to allow alternative delivery of sent email to alternate locations. For example we can use Scoped Send Connectors, which allow different outbound mail flow logistics in different AD sites, or we can deploy alternate gateways separate to Exchange that can handle this logic on our behalf.
 
So let's have a look at what we currently can do without a custom transport agent.
 
Use a third party gateway that can support the desired outbound logic
This will have a single Send Connector for general outbound mail delivery to a third party appliance. In this example the third party appliance is on-premise.
 
 
 
Use multiple AD sites
(even if they are within the same physical location) and incur the costs of this solution and utilise Scoped Send Connectors. The use of Stretched DAGs in this example is not a requirement, but invokes a higher level of resilience. Users in AD SITE 1 will utilise the outbound connector for general internet mail there, whilst users in AD SITE 2 will use the Scoped Send Connector valid for that AD site.
 
 
So what does SetRoutingOverride allow us to do? Well basically we create multiple Send Connectors. That's it. Each Send Connector has a dummy address space and your custom Transport Agent monitors all mailflow and for outbound messages that matches the trigger and then activates the routing override to push the mail to a specific address space. This in turn is matched to a Send Connector to a specific MTA, mail hygene platform or even directly for outbound routing and delivery to the external recipient.
 
Whilst this blog post will not show you how to code the actual custom transport agent (hey I'm not a developer – check the MSDN documentation and code examples) there are many ways to make this work. For example, should all logic sit within the actual transport agent? Should the custom transport agent have a config file local to the Exchange Server in question? Should the custom transport agent on all Exchange Servers look to a specific network based configuration file or indeed pull their configuration in remotely for a complete seamless and automated update of it? This is all up to you and how you need to make it work.
 
I will however show you examples of how to configure and monitor Exchange to prepare your environment for this.
 
The best way to explain this routing override method is to take the source 'From' address, and then push any mail for that down to a specific connector. It doesn't specify a connector but rather an 'override' address space to push the message to. So we create a Send Connector that just so happens to have the address space in question.
 
For example:
 
All mail sent from "contoso.com" addresses = "override" and send to "foo.foo"
All mail sent from "tailspintoys.com" addresses = "overrisde" and sent to "foo2.foo"
 
This doesn't rewrite the email at all or modify the headers, it simply tells the Transport service to deliver the email via a specific Send Connector because it matches the address space of "foo.foo". It's better to use a mythical address space that will never exist so as to never get into a situation where it becomes a real destination domain!
 
Let's take a look at what this means:
 
When a "contoso" user sends a mail that message is routed through to the preffered external smarthost for delivery:
 
When a "tailspintoys" user sends a mail that message is routed through to the preffered external smarthost for delivery:
 
 
So let's take a look at a real world example.
 
I have an Exchange 2013 combined role server, and two possible outbound paths to trusted premium AS/AV providers. MimeCast and Symantec.Cloud. I will check the configuration of the Send Connectors using Get-SendConnector
 
One for MimeCast
 
One for Symantec.Cloud
 
I will enable my install my custom transport agent and ensure it is enabled. You install your agent using the Install-TransportAgent cmdlet, you can enable or disable it, or change its priority using the Set-TransportAgent cmdlet. We will check to ensure the agent is installed and enabled using Get-TransportAgent.
 
Get-TransportAgent will show you all installed agents – including agents available out of the box like the text messaging agents and the free Malware Agent based on Microsoft Forefront that ships with Exchange 2013.
 
 
At this point I have set the custom transport agent to push all mail to Symantec.Cloud. Let's send a message and then check the headers.
 
Now I'll modify the custom transport agent to push the email through MimeCast. The custom transport agent I am using picked up the routing override from a text file local to the server.
 
Let's modify it.
 
Browsing to \\Exchange Server\TransportRoles\agents\ I will modify the config file. I now specified that for all users with the 'from' address matching "2013POA.co.uk" to now override the routing and push to "mimecast.sbr". It will now match this against a Send Connector.
 
 
I'll restart the Transport Service:
 
 
And then resend my message.
 
Let's check the the message headers now:
 
We can see it was sent outbound via the MimeCast Send Connector.
 
So that's it. Whilst this post doesn't cover the development of a transport agent dll to modify transport behaviour, we can see how the  SetRoutingOverride method works.
 
In this example the Transport Agent took its configuration from a local text file, but as said previously this can be developed many ways.
 
You can use this to create multiple Send Connectors for different organisations or units within your business, allowing your custom transport agent to then selectively choose which preferential outbound route is required.
 
Take care
 


Oliver Moazzezi - MVP Exchange Server


 
 
 
 
 
 
 

Tuesday, 17 March 2015

Exchange 2013 CU8 released

Today the Exchange Team announced the readiness and release of Exchange 2013 CU8.

New features include:

Calendar and Contact Modern Public Folders are now supported in OWA
Migration for Public Folders to Exchange 2013 including throughput and experience improvements
Smoother support for Exchange Activesync (EAS) clients to O365 when mailboxes are moved in a Hybrid Configuration

The full announcement can be found here, and remember CU8 updates your Active Directory schema.

Oliver Moazzezi - MVP Exchange Server

Tuesday, 3 February 2015

Office365 Cloud Solution Provider Program Part 2: Portal Review

So what does the Partner portal look like for a Cloud Solution Provider Reseller? Well the answer is not a lot different. I've flagged two test tenants, one setup under the old method and marked as 'Advisor' and a new tenant under the CSP:


You can see the partner portal clearly defines which program you have your tenant under. The three differences between them that are visible in the portal, other than the relationship confirmation are:

For Advisor the subscription data is unavailable:


For Cloud Solution Provider, we can directly edit the customer, perform actions to manage their services and the subscription data works correctly:


Once you move over to the CSP program by default new customers are created under the Cloud Solution Provider relationship. Setting up a new client manually is the same experience:



Select the initial plan and seats


Then review and complete


As the CSP is meant for provisioning large numbers of seats fast, and easily, I can't foresee providers manually setting up customers. From Microsofts very own Office Blog here we can see the following statement, "Partners in this program will be able to directly provision customer subscriptions and provide one monthly bill for both Partner and Microsoft services".

So what does this mean? Taking it on face value it suggests that there will be a direct way to provisioning both customer subscriptions and allow the Cloud Reseller to provide one bill to their customer. To me, this means that automation will be necessary, most likely through an API.

This is an interesting story, there are already APIs that we can take advantage of to manage services in Office 365. We can see there is already a REST API which is documented for developers on MSDN here, and an Azure specific REST API, Azure AD Graph.

It will be interesting to see what Microsoft will do, if anything, to provide the tools and capabilities to allow Cloud Resellers to achieve their vision of 'direct provisioning' and 'unified billing'.

Once more information is made available I will share, and attempt to show such 'direct provisioning' and 'unified billing' capabilities.


Until next time, take care.



Oliver Moazzezi - MVP Exchange Server
@OliverMoazzezi

Friday, 30 January 2015

Microsoft Cloud Solution Provider Program

Microsoft launched the CSP at The Microsoft WorldWide Partner conference in 2014, but only now the fruits of Microsofts efforts are starting to be seen in Office365.

You have to qualify to be considered as a CPS partner, but qualification doesn't automatically mean acceptance yet – for the time being you must be accepted also.

There are currently 2 tiers to the CSP, outlined below.

1-Tier is the program of choice for partners looking to provide an end-to-end customer experience, including customer support. In this model, the partner has a direct relationship with Microsoft. This program requires partners to have high capability standards to provide a great customer experience.

2-Tier is designed for resellers to work with their 2-Tier distribution partners to sell Microsoft cloud services. In this program, the 2-Tier distribution partner provides reseller and customer support. Most partners will participate in the CSP program as a 2-Tier reseller


The biggest changes for a typical O365 reseller will be owning the entire billing cycle, and taking on the entirety of the support for your tenants, instead of the tenants raising issues to Microsoft directly. This means you are going to need, if you want to be successful and grow your O365 CSP tenant offering, a 24/7 support team – primarily delivered over the phone.

So what are Microsofts expectations of a Cloud Provider signed up to the CSP?

Own and control the billing
  •   Provide customers with one consolidated bill, monthly or annually
  •   Order from a wholesale price list, create unique offers, and set the price
  •   Create financing options, such as spreading upfront costs over the fiscal year

Sell integrated offers and services
  •   Introduce service offers across each stage of the customer lifecycle
  •   Include your tools, products, or services in one integrated sales motion
  •   Increase upsell opportunity with greater customer touch points

Provision, manage, and support
  •   Directly provision and manage your customers' tenant with in-product tools
  •   Address customer technical support issues as admin-on-behalf
  •   Drive customer satisfaction as the first point of contact

This is all interesting stuff, the Microsoft focus appears to rely on the expertise of Cloud Providers knitting together an O365 support model and customer experience without Microsoft having to take the hit in the support cycle – we all know the apparent burden of O365 support on Microsoft and that raising tickets as an O365 customer hasn't provided the best experience. It makes sense that Microsoft are looking to de-emphasise support and most likely at the same time increase their revenue from the service.

One of the other immediate apparent benefits is the power and focus of automation for many Cloud Providers – O365 is great – but currently all products and services are Microsoft – with an active Cloud Provider with good standing relationships with many vendors I can foresee customers being able to purchase their O365 services and actually selecting other services in the service wrap – all automated, setup and integrated and hybridised by the Cloud Provider – with a single unified bill to the customer – fantastic.

More information can be found here and here

Come back next week as we take an active look at the O365 Portal as a CSP enabled Partner. See you then!


Oliver Moazzezi - MVP Exchange Server


Tuesday, 20 January 2015

Installing an Office OWA app manifest file in Exchange 2013 (Part 2)

In Part 1 I went through installing an OWA manifest file either through the ECP, or via the Exchange Management Shell that wasn't part of the Office Store. In this part I wanted to cover how to push an App out to selected users as well as scripting deployment .

Restricting Apps to a Distribution Group via 'SpecificUsers'


1. Get the Distribution Group, and then in the Exchange Management Shell run the following

Get-DistributionGroup "Group Here"



2. Once you have confirmed the DL, run the following

$group= Get-DistributionGroupMember "All Users Security Group Name"

Note we have changed the command to "Get-DistributionGroupMember"



3. To install the App to the the users in the DL run the following command

New-App –OrganizationApp –ProvidedTo SpecificUsers –userlist $group –DefaultStateForUser enabled –url "your manfiest XML file url here"

As mentioned in Part 1, if you want to force the app to be always enabled and disallow the users from disabling it you can set –DefaultStateForUser to –DefaultStateForUser AlwaysEnabled. Similarly if you want the app to be available but only enabled by the user you can set it to Disabled

Alternatively if you have the app already installed you can run:

Set-App –OrganizationApp –ProvidedTo SpecificUsers –UserList $group –DefaultStateForUser Enabled –Identity "App ID (GUID)"

This will change the state of the App to specific users and set it to enabled, again, modify –DefaultStateForUser as you so wish



4. Once the App has been set to Specific Users you can check it using the EAC:



5. You will find the Distribution Group members now have the app, and all other users do not. There are other ways of selecting users however, we could have for example performed

"Get-Mailbox –OrganizationalUnit "DistinguishedName of OU" instead of "Get-DistributionGroupMember"

Therefore we could use "$users = Get-Mailbox –OrganizationalUnit "DistinguishedName of OU"



Scripting via Powershell

So pushing an App out to specific users is great, but the delivery method doesn't take into effect new users joining the Distribution Group or Organizational Unit as well as users that are removed. For that we need to use a script. The below scripts can be used as a scheduled task, and will push the App out to the specific users required. One is for DL delivery and the other via OU. The only two I have so far needed.


#Install Office App to single Organizational unit

#SPECIFY OU DISTINGUISHEDNAME HERE
$users = Get-Mailbox -OrganizationalUnit "DistinguishedName of OU here"
$tenant = Get-OrganizationalUnit "DistinguishedName of OU here"
$tenantidentity = $tenant.name
$xmlmanifest = "URL to manfifest file"

#Start
Write-Host The total number of mailbox enabled users found for $tenantidentity is ($users).count -foreground yellow
New-App –OrganizationApp –ProvidedTo SpecificUsers –userlist $users –defaultstateforuser enabled –url $xmlmanifest
Write-Host Office App installation complete for $tenantidentity -foreground yellow


#Install Office App to for Distribution Group

#SPECIFY DISTRIBUTION GROUP HERE
$Group = Get-DistributionGroupMember "Security Group Name here"
$tenant = Get-DistributionGroup "Security Group Name here"
$tenantidentity = $tenant.name
$xmlmanifest = "URL to manfifest file"

#Start
Write-Host The total number of mailbox enabled users found for $tenantidentity is ($Group).count -foreground yellow
New-App –OrganizationApp –ProvidedTo SpecificUsers –userlist $Group –defaultstateforuser enabled –url $xmlmanifest
Write-Host Office App installation complete for $tenantidentity -foreground yellow


That's it for now, take care.

Oliver Moazzezi - MVP Exchange Server