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



Friday, 16 January 2015

Installing an Office App manifest file in Exchange 2013 (Part 1)

It's very easy installing an Office App into Exchange 2013, users have the capability themselves should you allow it, but what happens if you want to publish an App that isn't available in the Office Store? You may have created your own App or want to install a bespoke unpublished app from a trusted third party or partner company for example. Read on..


1. In the EAC browse to Organization | Apps



2. Select to install the App. You have the choice of 'Url' or 'file' as well as from the 'Office Store'



3. In this instance I am installing from URL, adding my URL to the file for the custom app I want to install



4. Once it is installed you will see it is disabled by default:



5. Edit the app to enable it:

And that's it! It's installed and available for everyone, but what if we want to push an app to specific users or push an app out via the Exchange Management Shell?

6. We can install the App via the Exchange Management Shell:

"New-App –OrganizationApp –Url "URL to Manfifest XML here"




7. Ensure the commands completes, it will show the DisplayName of the app, whether it is enabled and the App version number




8. If you use "Get-App" it will show all Apps, including the one you've just installed from your manifest file



9. However using "Get-App –identity "Bing Maps", for example will not specifically target an App.



10. Selecting "Get-App |select DisplayName, Identity" yields a mailbox and GUID based Identifier



11. You need the GUID to select the App. You have to use that against the –Identity parameter. 'Get-App –Identity "Domain/Mailbox/GUID"'



12. When logging in as a user in OWA, you will see your Apps, in this example, Bullhorn is available to enable



If you want to enable it via the Exchange Management Shell you can do this via the Set-App cmdlet.

"Set-App -Identity "App ID (The GUID)" -Enabled $true"


Similarly, if you wanted to push the Apps to users and not let them disable the App, we can again use  Set-App but this time using the -DefaultStateForUser parameter. If we specify -DefaultStateForUser AlwaysEnabled, the user will not be able to disable the App.

That's it for now, in Part 2 I will show you how to restrict the App to specific users as well as provide some scripts to automatically roll out Apps to new users as and when they join the company, ensuring your users are pushed the specific apps your company requires.

Oliver Moazzezi - MVP Exchange Server

Invoking Pool failover when one Pool is the CMS

There are a lot of articles talking about Lync Front End Pool failover on the internet. Some are Technet articles relating to Standard Edition Servers like this one. Whilst others talk about the concept.

I wanted to go through a very real world scenario that I did this week, with it coming up with a few real world experiences I wanted to share with you.

So let's take a look at the scenario:



The topology is as follows:

1. There is a Front End Pool hosting the CMS in Site 1
2. There is a Front End Pool in Site 2
3. The Front End Pools are Backup Registrars for each other
4. The Edge Pool in each site has the retrospective Front End Pool in the same site as its next Hop
5. Access Edge for external users in Site 1 is: access.exchange2010.com
6. Access Edge for external users in Site 2 is: access2.exchange2010.com
7. Both Front End Pools have their own Backend SQL databases in the site the Front End Pool is in, we are not stretching any SQL services over sites.


First things first, before failover over the Pool to the Backup Registrar there's other things to consider.

So how do we make the user that is currently connecting to access.exchange2010.com connect to the other Access Edge? In normal circumstances you don't have to worry about this as hopefully things won't break, but I found for the Lync client to successfully connect to a secondary Access Edge FQDN I had to ensure the second record was in public DNS with a different weight to the primary, or preferred Access Edge FQDN. Then in the event all your Edge servers were down, inaccessible, or failed it would automatically connect to the other Access Edge.

Example:


And utilizing the Weight:


If you didn't want to do this then simple updating your _sip records to point to an alternative Access Edge would be absolutely sufficient, or manually updating each client (not fun) to the alternative FQDN.

  

Now we've got that out of the way, let's look at invoking Pool failover when one Front End Pool is the CMS!


1. First of all confirm Replication is fine using Get-CsManagementStoreReplicationStatus, there's absolutely no point performing this failover if replication is broken (unless you are in a real DR scenario!)



2. If at this point we try to fail over the Pool in Site 1 that is the CMS, we will get a failure saying it is the CMS and the CMS must be moved, so let's do that. We simply use the command Invoke-CsManagementServerFailover, as the pools are paired this command will know to move the CMS over to the Backup Registrar, which is the Front End Pool in Site 2. Select Y to confirm the move.





3. Once the CMS is failed over we now need to perform another task before we can invoke a pool failover, we need to move the Edge Pool dependency. We do this using the Set-CsEdgeServer command (we can also use the Topology Builder, but the management shell is far simpler here, and in DR scenarios we may be stating away from publishing topologies until we are in a semi working state).

What we are doing here is removing the association of the Edge Pool in Site 1 with the Front End Pool in Site 1, and now binding it to the Front End Pool in Site 2.



4. We are now in the position to fail the pool over using the Invoke-CsPoolFailover command. This is simply run as 'Invoke-CsPoolFailover –PoolFQDN "Site 1 Front End Pool FQDN"'. If this is an actual disaster then we can also add the –DisasterMode switch, but if the pool is up and working there's no need to add this.


That's it, you'll find all users will switch over to using the other pool. Moving the users back is just a case of running 'Invoke-CsPoolFailBack –PoolFQDN "Site 1 Front End Pool FQDN"' – and don't forget to move the CMS back if you so desire!




Oliver Moazzezi - MVP Exchange Server


Tuesday, 16 December 2014

Exchange 2013 OAB generation and FIPS

Recently on a new Exchange 2013 platform that is being built OAB generation and thus the OAB downloads to the Outlook client were not working.

Checking Event Viewer, there were a lot of 17004 events stating that the generation of the OAB was failing:


More interestingly when scrolling through the detail it mentioned FIPS, or 'Federal Information Processing Standard'. You can see in the below screen shot it states:

"System.InvalidOperationExeption: this implementation is not part of the Windows Platform FIPS validated cryptographic algorithms".


After ensuring there were no Group Policy templates applied to the server, I opened the Local Security Policy MMC | Local Policies | and checked the Security Options:


And I could see FIPS was enabled. Disabling it on all the Mailbox Servers that perform OAB generation resolved the issue (disable it on all though if it is a DAG as the mailbox database will move!!!), and the Outlook client could then download the OAB.


But what was the issue here?

Well a look on Bing/Google gave the following Microsoft KB article . It appears the SHA1 hash algorithm that is used for the OAB file hash is not FIPS compliant – thus the OAB generation fails. The platform that is being built is based on Exchange 2013 CU5, as we cannot go to CU6 yet until this is planned – hence the error occurred in all Sysprepped images that have FIPS compliance set to enabled in the local security policies.

This issue however is resolved in Exchange Server 2013 CU6 as it will update the hash algorityhm for OABs , so if you require FIPS compliance ensure you are at least at CU6. 

It appears that as of 3/12/2014 that the health set monitors for Exchange 2013 have been updated to include FIPS. See 'Troubleshooting FIPS Health Set' here.


Oliver Moazzezi - MVP Exchange Server






Wednesday, 12 November 2014

Lync Room System won't show the Exchange Calendar


Recently I ran into an issue that is specific to certain hosting scenarios (Office 365 or other), or in some circumstances on-prem environments also for Lync Room Systems (LRS).

An LRS system cannot connect to a Lync environment if the top level domain of the LRS account, for example, LRS@domain.com is not present in the SSL cert on either the Edge, for external connectivity, or the Director or Front End Pool for LRS systems deployed internally.

In nearly all scenarios you will ensure your SIP domains are in your certificates, but some companies don't add all of them accepting functionality caveats, and for Lync Online and Lync Hosting Pack v2 you simply cannot add all tenants domains to certificates, so redirection of tenants domains to a hosting access edge is inevitable.

Taking a look at the SMART LRS setup documentation (as I had a SMART system to setup!) here you can see on page 72 that it is necessary to modify the registry with a TrustModelData key to allow LRS to connect to a Lync deployment where indeed the top level domain (TLD) for the LRS account is not in the cert.



If this key is not added the LRS system sits on a blank screen, whilst the certificate warning is hidden behind the LRS walled garden, never allowing you to go any further. What certificate warning you say? Well one like this:


Adding the key and restarting the LRS system tells LRS that the TLD from the certificate, even though it does not match the TLD for the LRS account, is trusted and this certificate warning does not appear. Therefore the LRS can start successfully and can log into Lync via the LRS console without issue. (If you are wondering how to get the registry up on LRS, check the screenshot from the SMART documentation I have pasted above, this is the same procedure for all LRS systems).


But what I found once LRS was rebooted was that the Exchange Calendar would not load.


I checked that the LRS system could actually contact the autodiscover service by manually authenticating directly on the LRS system against EWS (Exchange Web Services) with the LRS account in question.


I was stumped. A quick PSS call confirmed there's an LRS bug, and that you have to give 'Everyone' 'Full Control' on the HKLM\Software\Microsoft\Office\15.0\Lync registry entry to get the Exchange calendar to show..



Once this was applied and the LRS rebooted the Exchange Calendar still wouldn't show, so I went to verify that I had indeed set the permission correctly. It was during this time that I noticed another TrustModelData key – prepopulated with Lync Online – but more specifically Exchange Online TLDs:



So I added the hosted Exchange TLD (in my instance the Lync Edge TLD and Exchange TLD matched) of the certificate to this key and restarted LRS.

When LRS restarted I again received the dreaded loading symbol for approximately 20 seconds, before the calendar showed in full glory!



Conclusion

This isn't going to affect all customers that deploy LRS systems, if you included all SIP domains in all certificates (Edge and internal) this isn't going to affect you. But this will affect Office 365 LRS deployments and any customers that use multi tenant Hosted Lync and Hosted Exchange deployments.

For Office365 customers it appears all  TrustModelData registry entries have been pre-populated through the LRS update program (ensure you are up to the latest LRS update, I was), however you will have to perform the permission change to allow everyone full control for it to work.

For other hosted environments you will have to ensure the TLD is added to the TrustedModelData key as well as performing the permission change to allow everyone full control.

LRS should then login and also show the associated Exchange calendar just fine.

On a side note I'll post the full end to end deployment and configuration steps for Exchange 2013 hosting guidance and Lync Hosting Pack v2 in the coming days. Watch this space!

Take care

Oliver Moazzezi - MVP Exchange Server



Tuesday, 14 October 2014

Google Chrome Browser and Outlook Web App and Exchange Admin Center issues

Microsoft have released a kb alluding to all the 'showModalDialog' issues customers have been having when using certain Office365 web portal or Outlook Web App and Exchange Admin Center settings when using Google Chrome as their web browser.


The current fix is classed as a workaround, meaning most likely a permanent fix will be put in place at a later date. As this is a deprecated feature it is likely an update to Exchange will fix this issue. We will have to wait and see!

The work around is detailed below:


1. Click Start, type regedit in the Start search box, and then click regedit.exe.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\EnableDeprecatedWebPlatformFeatures

3. On the Edit menu, point to New, and then click String Value.
4. Type 1, and then press Enter.
5. Right-click the 1 string value that you created, and then click Modify.
6. In the Value data box, type ShowModalDialog_EffectiveUntil20150430, and then click OK.



If the key is missing entirely under ..\\SOFTWARE\Policies we need to create it.

Seeing as my workstation was missing this I thought I'd take a few screen shots of the process for those small shops that are using Office365 are don't necessarily have any IT experience.



Right click Policies and select New > Key and enter Google


Create sub keys for Chrome and EnableDeprecatedWebPlatformFeatures as shown


Finally enter the key as mentioned.


Take care

Oliver Moazzezi - MVP Exchange Server