In the early days of Office 365, you would be accustomed to a certain kind of experience when purchasing licenses as a small/medium size business (SMB) customer. As these types of organisations are typically too small to warrant the cost for Enterprise Agreements or Volume Licensing, your only recourse to buying Office 365 services was via the portal itself. At this time, any involvement with a Microsoft Partner would be minimal or even non-existent. Partners would only enter the picture if a business opted to grant them Partner of Record status, thereby allowing them to manage aspects of your subscription behind the scenes. This process, while wholly sufficient, did have some notable gaps and, if you were an organisation focused on tightly managing all aspects of your customer journey, could be prone to change or interruption via interference from Microsoft

The Cloud Solutions Provider programme (or CSP for short) is Microsoft’s “next-generation” opportunity for partners to get directly involved as part of a customers journey onto Office 365, Dynamics 365 and/or Azure and aims to resolve some of the issues highlighted above. Instead of turning directly to Microsoft when you need a new license subscription or have an issue with a particular Office 365 opportunity, customers would instead deal directly with a CSP provider, who will be able to offer them all of this, and more. Everyone wins – the customer, CSP provider and Microsoft itself – and here’s just a few reasons why:

Moving to CSP can save you money

Perhaps the most important reason of all to consider CSP ūüôā The price you will pay for pretty much every single Office 365 Subscription offering available via Microsoft directly will be lower if purchased from a CSP partner. In most cases, this will typically result in a 10-15% reduction across the board guaranteed; a figure which, depending on the size of your organisation, could be a significant portion of your per annum IT spend. In addition, there is no need to wait for your subscription anniversary to switch – any early cancellation charges will be credited in full by Microsoft, should you cancel at any point in your subscription and migrate to the equivalent CSP subscription.

CSP users can benefit from special promotions, previews and other deals unavailable via Microsoft Direct

One example of this at the moment is the preview for Microsoft 365 Business Рthe next evolutionary step for Office 365 Рwhich is accessible to those who are working with CSP providers currently. Other promotions may also appear from time to time, so you should be speaking to your CSP provider regularly to ensure that they are informing you of any potential discounts or offers available.

CSP enables your current Microsoft Partner to support you better

If you are working with a Microsoft Partner to help support your Office 365 services or Dynamics 365 deployments, there’s a good chance that they may have spoken to you about CSP or migrated you across already. The reasons for this will not be purely based on an altruistic desire to reduce your monthly running costs; by having their customers operating under CSP licensing, Partners are granted additional information regarding your subscriptions and their usage. They also become the¬†de facto organisation that needs to be contacted in case any issues occur relating to the subscription. A customer who, for example, contacts Microsoft directly regarding an Exchange Online issue on their CSP subscription will instead be referred back to the CSP Partner in the first instance; they will then be responsible for escalating the case to Microsoft if required. In most circumstances, this can surely be seen as a plus and in helping Partners to work more closely with their customers.

The above example also goes some way towards explaining why CSP license prices are cheaper compared to going directly to Microsoft. By placing Partner organisations at the front-line of dealing with common 1st/2nd Line support issues, Microsoft can reduce the number of support professionals it allocates internally ¬†and place the burden instead on Microsoft Partners to do the “heavy lifting”, particularly when it comes to dealing with easy to resolve issues (i.e. any support request that can be resolved via the Administration Centre).

It’s for Azure as well…with some caveats

Chances are if you are using Office 365 within your organisation, then you will also be consuming some additional Azure services on top of this – either Virtual Machine(s), storage, websites or even some database capacity. The good news is that you can also look at moving your Azure subscriptions across to CSP, with the same benefits available: reduced monthly costs and the ability for your partner of choice to support you better.

At the time of writing this post, the key “red flag” I would draw you towards when considering Azure CSP is what you lose compared to a Pay As You Go or other direct subscription. For example, ongoing and previous usage history will not be visible on the Azure portal and, chances are, you will only get full visibility of your Azure usage costs at the time when you are billed by your CSP partner. If you typically prefer to micro-manage your ongoing Azure usage costs, then a 10-15% saving may not be a fair trade-off for losing this visibility.

Finally, don’t be surprised if this becomes the de facto way of buying Office 365/Azure in the future if you are an SMB

I mentioned above one reason why CSP license costs are cheaper, and through this, you can begin to see the writing on the wall for SMB’s. This is not necessarily a bad thing. My own personal preference would be in dealing with a Microsoft Partner as opposed to Microsoft direct, as Partners will generally be a lot more flexible and reactive to work with. Having assumed that Microsoft can generate significant¬†internal cost savings and also give eager Partner organisations the opportunity to fill the void, why would they not then turn round and say “We’re sorry, but if you are an organisation that employs 300 people or less, then please speak to a Microsoft Partner for further assistance.”? Certainly, the vibe and talk around CSP at the moment would seem to indicate that this is the long-term trajectory for the programme. Watch this space, but it will be interesting to see in the future whether the Microsoft Direct route is downplayed or removed completely if your potential license order per annum is in only in the hundreds of ¬£’s.

We saw previously on the blog some of the great features that you have at your disposal when using Office 365 Groups in conjunction with Dynamics CRM/Dynamics 365 for Enterprise. When deployed prudently, they can massively enhance what is traditionally possible via distribution groups and give internal/external users a better way to collaborate with content, as opposed to a mountain of email attachments. As I cautiously hinted towards in the above post, some thought should go into how you go about rolling out Office 365 Groups across your organisation, which should inevitably include internal testing. By doing this, you can highlight a particular functionality quirk that you will more than likely need to address before issuing a general rollout.

When you first go to create an Office 365 Group, you will notice that the domain address of the newly created group mailbox has defaulted to the onmicrosoft.com domain for your Office 365 tenant, instead of any bespoke domain you may have setup on your tenant:

You would think that this is caused by the fact that the Default Domain for the tenant is still set to the onmicrosoft.com domain, as we can see below:

However, after changing this accordingly, we are still forced to create a Group email address that utilises the onmicrosoft.com domain:

Rather frustrating! Fortunately, there is a way in which we can get around the issue, which involves two steps if you have existing Office 365 Groups that need renaming:

  1. Modify the Email Address Policy for your tenant via PowerShell to force new Groups to use your desired domain.
  2. Update the SMTP address of all existing groups via PowerShell.

Both of these steps will now be demonstrated, but be sure to have PowerShell installed on your machine first before you begin.

Connecting to your Office 365 tenant

Start your PowerShell client as an Administrator (Run as Administrator option on Windows) and execute the following command first to ensure all subsequent scripts run correctly:

Set-ExecutionPolicy RemoteSigned

You should receive a prompt similar to the below:

Press Y to proceed

Now we are ready to connect to Exchange Online, using the following cmdlets:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

You’ll be prompted to enter credentials to authenticate:

Make sure the credentials used have the relevant privileges on Office 365 and then hit OK. After a few moments, you should see a window similar to the below, which indicates that you have successfully connected and have all the Exchange Online cmdlets at your disposal:

Set Default Email Policy for Office 365 Groups

Modifying Office 365 to use a different domain when creating Office 365 Groups requires invocation of the New-EmailAddressPolicy cmdlet, a broad brush command that is useful for a number of different Exchange management scenarios. The command can be specifically tailored to create a policy applicable to Office 365 Groups, basically telling your tenant which SMTP domain to use when creating new Groups:

New-EmailAddressPolicy -Name Groups -IncludeUnifiedGroupRecipients -EnabledEmailAddressTemplates "SMTP:@mydomain.com" -Priority 1

You can tell if the command has executed successfully if you see something similar to the below in your PowerShell window:

Next, we can then verify that Office 365 has detected the change by creating a new Group and verifying that the Email address value reflects our desired domain:

Rename Existing Office 365 Group

Assuming you are just starting out with Office 365 Groups, the simplest way of renaming your existing groups would be to recreate them. This may not work if they are already being utilised, given the level of effort involved in migrating existing content across to a new group. In this scenario, there is an additional cmdlet we can rely upon to change the SMTP address of our group to our desired domain:

Set-UnifiedGroup -Identity "Test Office 365 Group" -PrimarySmtpAddress test@mydomain.com

PowerShell will only return a message in case of an error, so to verify our changes have taken place, we must again return to Office 365 to confirm that the new SMTP address is in place:

With this now updated, email messages should flow successfully to the new Group SMTP address.

Conclusions or Wot I Think

It is rather strange that there are no obvious means of specifying which default domain should be used with newly created Office 365 groups, nor at the fact that there is any way for the user to override their choice so they can select a domain that is available on the tenant. As discussed at the start of this post, this situation provides an excellent argument for ensuring that proper processes are followed for the introduction of all new technologies within the business. Whilst exciting and innovative solutions should always be duly considered and not hampered from being rolled out, it is crucial that an appropriate amount of time is allocated for thorough testing. The last thing you want to do, in reference to this situation, is to cause irritation to end users by not giving them the ability to present a professional and correct domain name for their Office 365 Groups; by running through some test scenarios and involving end users as part of this process, where possible, you can help to prevent issues resulting from a roll out and (hopefully!) enthuse colleagues within your organisation at the new piece of technology that is being introduced.

Getting to grips with how to use Dynamics CRM/365 for Enterprise (D365E) is no easy feat. You can imagine just how difficult it is for an end user to get to grips with how the application works and functions; with more detailed knowledge around customisation and development being an entirely different ball game altogether. Compounding this problem further is the fact that the product has evolved at an increasingly more rapid pace over recent years, to the point where it is literally impossible to become a master of¬†everything that you can do within CRM/D365E. Those venturing into the product for the first time may find their learning journey significantly simplified if they already have a good general knowledge about some of the underlying technology that powers CRM/D365E. This was certainly true in my case; I had a good background already in managing Office 365, writing SQL queries/reports and some experience with C#. This is all incredibly useful knowledge to have in your arsenal and is all directly applicable towards CRM/D365E in some way. For those who are getting to grips with the product for the first time, either without this previous experience or as part of an apprentice/graduate type role, your journey may not be as swift and issue-free. With this in mind, here’s my list of essential knowledge that you can add to your own “swiss army knife” of personal knowledge. Experience and good knowledge of these technologies will not only help you greatly in working with CRM/D365E, but present an excellent learning opportunity for Microsoft technologies more generally and something that you can add to your CV with pride:

SQL Server

What is it? :¬†SQL Server is Microsoft’s proprietary¬†database knowledge, based on the ANSI standard. SQL stands for Structured Query Language and is one the most widely used database programming languages on the planet.

Why Knowing It Is Useful: The underlying database technology that CRM/D365E uses is SQL Server, so having a general awareness of relational database systems work and how SQL Server differs from the standard goes a long way in understanding what is capable from a customisation/development viewpoint. For example, you can very quickly grasp which data types the application supports, as they will all ultimately be based on a supported SQL Server column data type. If you are running on-premise versions of CRM/D365E, then knowledge of SQL Server immediately moves from being a nice bonus to an essential requirement. This is because administrators will need to have good knowledge of how to manage their Dynamics CRM database instance, perform backups and also, potentially, write transact-SQL (T-SQL) queries against your database for reporting or diagnostic work.

Recommended Area of Study: Focusing your attention towards SQL Server Reporting Services (SSRS) report writing will benefit you the most. Through this, you can begin to establish good knowledge of how SQL Server databases work generally, and be in a position to write FetchXML for Online/On-Premise deployments of the application or Transact-SQL (T-SQL) based reports for On-Premise only. Having a good awareness of what is capable via a standard SQL query will also hold your good stead when working with FetchXML, as you can immediately make a number of assumptions about what is possible with FetchXML (for example, filtering results using an IN block containing multiple values and performing grouping/aggregate actions on datasets)

Office 365

What is it? : Office 365 is Microsofts primary – and perhaps most popular – cloud offering for businesses, individuals or home users. Through a wide array of different subscription offers, home and business users can “pick ‘n’ mix” the range of solutions they require – from Exchange-based email accounts to licenses for Microsoft Visio/Project, through to PowerBI.

Why Knowing It Is Useful: Although it is arguable that knowledge of Office 365 is not essential if you anticipate working with on-premises versions of the application, you may be doing yourself a disservice in the long term. Microsoft is increasingly incentivising organisations to move towards the equivalent cloud versions of their on-premise applications, meaning that as much knowledge as possible of how CRM/D365E Online works in the context of Office 365 is going to become increasingly more mandatory. If you are looking to secure a career change in the near future, and have not had much experience with Office 365, then this is definitely an area that you should focus on for future learning. From a day-to-day management point of view for the Online version of the product, some basic awareness of how to navigate around and use Office 365 is pretty much essential if you are going to succeed working with the product on a day-to-day basis.

Recommended Area of Study: Spin up a D365E trial, and you can very quickly start getting to grips with how the product sits within the Office 365 “ecosystem”. Practice licensing users, configuring security group level access to your D365E¬†trial tenant and modify the details on Office 365 user accounts to see how these details are synced through into D365E.¬†The Microsoft Virtual Academy also has a number of general courses related to Office 365 however, due to the frequent updates, it may not always be in-line with the current version. The official curriculum/certification paths for Office 365 may also suffer the same from this but are worthwhile in demonstrating your experience and ability to integrate D365E with the various related Office 365 services.

Active Directory

What is it? :¬†For the rookie, intermediate and experienced IT admins, Active Directory needs no introduction.¬†It¬†is essentially Microsoft’s implementation of the Lightweight Directory Access Protocol (LDAP), having first being introduced in Windows Server 2000, providing a means of managing user, security and access rights for domain objects. There are now two distinct versions of Active Directory that are available – the more traditional, Windows server based, on-premise Active Directory and Azure Active Directory, which is utilised primarily by Office 365.

Why Knowing It Is Useful:¬†User account records for both On-Premise and Online versions of CRM/D365E use Active Directory objects, with a number of important information synchronised between an Active Directory user and the equivalent User entity record. For example, as indicated in this MSDN article, the only way in which you can synchronise a user’s Job Title through to CRM/D365E is by updating the equivalent field on the Azure Active Directory. Active Directory objects are also the only way in which you can authenticate with the application via the Web Interface or other means, with no option to create a database user or other kind of authenticated user type.

Recommended Area of Study:¬†It’s free to set up your own Azure Active Directory, so this is an excellent starting point for getting to grips with the technology. There’s also nothing preventing you from downloading a trial of Windows Server and installing the Active Directory server role on this machine. Once configured, you can then start to create users, update attributes, configure permissions and setup roles that contain collections of privileges. If you already have an Office 365 tenant with CRM/D365E Online, then you can use the Office 365 portal to manage your user accounts and test the synchronisation of attribute values from the Active Directory through to¬†the application.

PowerShell

What is it? : A good way to remember what PowerShell is that it is essentially a blue command prompt window ūüôā . Traditionally only being relevant¬†and important for those working extensively with Windows Server or Exchange, PowerShell is now increasingly important as part of administrating on-premise CRM/D365E, Office 365 and Azure, to name a few. Indeed, one of the major shock announcements this year was that PowerShell became open sourced and can be installed on Linux; representing the increasing demand and importance of Linux-based resources within the Microsoft cloud.

Why Knowing It is Useful: Similar to SQL Server, PowerShell is something that is instantly more applicable for on-premise CRM/D365E deployments. For example, the only way to modify the default number of Dashboard items is via executing the Get-CRMSetting cmdlet against your on-premise organisation. I would also, again, argue having a general awareness of PowerShell can help greatly when performing administration work against an Office 365 tenant that contains a CRM/D365E organisation, such as user provisioning or license assignment. If you are utilising the Azure Service Bus to integrate CRM/D365E for Azure-based applications, then PowerShell immediately becomes a desirable skill to have in your arsenal, allowing you to remotely administer, deploy or update Azure resources programmatically.

Recommended Area of Study: The fact that PowerShell is now open sourced means that there is a plethora of online tools and guides to refer to, and you can be assured that you can get it working on your platform of choice. The GitHub page for PowerShell is a great place to get started. Beyond that, you have a few options about how you can practice further. If you have spun up a D365E trial, then you can choose to hook up PowerShell to Office 365 to see what you can do from a remote management perspective (such as granting Send On Behalf permissions for a shared mailbox). Alternatively, you can run it from your local Windows machine, connect it up to a Windows Server instance or attempt to create new services in Azure and experiment that way.

It is sometimes desirable to grant Send on Behalf permissions in Exchange for users who are accessing another mailbox in order to reply to email messages. Some typical scenarios for this may include a personal assistant who manages a company directors mailbox, a group of users who manage a central support mailbox or for ad-hoc scenarios, such as when a colleague is out of the office. Send on Behalf permissions provide the best level of courtesy when responding to an email by letting the person know that someone else is answering an email addressed to an individual, and I would say it is generally the more recommended approach compared to granting Send As permission.

Within Office 365/Exchange Online, we can very easily grant Send on Behalf permissions for a standard user mailbox (i.e. a user that has been granted an Exchange license on the Office 365 portal) via the user interface; just go into the mailbox in question, navigate to mailbox delegation and then simply add in the users who need the required permissions:

1

Then, give it twenty minutes or so and then the user can then send as this user from the¬†From field in Outlook successfully – nice and easy, just the way we like it ūüôā

But what happens if we wanted to grant the very same permissions for a shared mailbox? Say that we had an IT support help desk with a shared mailbox that several different users need Send on Behalf permissions for. Within the Office 365 GUI interface, we have options only to grant Send As and Full Access permissions:

2

So, in order to accomplish our objective in this instance, we need to look at going down the PowerShell route. Microsoft enables administrators to connect to their Office 365 tenant via a PowerShell command. This will then let you perform pretty much everything that you can achieve via the user interface, as well as a few additional commands not available by default – as you may have already guessed, granting Send on Behalf permissions for a shared mailbox is one of those things.

Microsoft have devoted a number of TechNet articles to the subject, and the one found here is an excellent starting point to get you up and running. The salient points from this article are summarised below:

  • Ensure that the latest versions .NET Framework and Windows PowerShell are¬†installed on your 64 bit Windows machine. These can be added via the¬†Turn Windows features On or Off screen, which can be accessed via the search box on your Windows Start Menu or in Control Panel -> Programs and Features ->¬†Turn Windows features On or Off,
  • Download and install the Microsoft Online Services Sign-In Assistant
  • Download and run the Azure Active Directory Module for Windows PowerShell

Once you’ve got everything setup, open up PowerShell and run the following script, altering where appropriate¬†to suit your requirements/environment:

# Remove result limits due to console truncation

$FormatEnumerationLimit=-1

# Connect to Office 365. When prompted, login in with MSO credentials

Set-ExecutionPolicy Unrestricted -Force 
Import-Module MSOnline  
$O365Cred = Get-Credential  
$O365Session = New-PSSession ‚ÄďConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection  
Import-PSSession $O365Session -AllowClobber  
Connect-MsolService ‚ÄďCredential $O365Cred

# Add additonal users to Send on Behalf permissions for mailbox. add= list if a comma seperate list. Each email address should be in double quoted brackets

Set-mailbox ‚ÄėMySharedMailbox‚Äô ‚ÄďGrantsendonbehalfto @{add="john.smith@domain.com"}

# Confirm that user has been succesfully added to send on behalf permissions for mailbox

Get-Mailbox 'MySharedMailbox' | ft Name,grantsendonbehalfto -wrap

# Display exit script (to keep window open in order to view the above)

Read-Host -Prompt "Press Enter to exit"

The nice thing about this code snippet is that you can grant multiple users Send on Behalf permissions at the same time, which is really handy.

Based on my experience, the above¬†has been a pretty regular request that has come through via support in the past. I am unsure whether this is common across different organisations or not; if it is, then I am really surprised that the Office 365 interface has not been updated accordingly. The important thing is that we can ultimately do this in Office 365, as you would expect via an on-premise Exchange Server. As such, organisations can be assured that if they are planning a migration onto Office 365 in the near future, they won’t be losing out feature-wise as a result of moving to the platform. And, finally,¬†it is always good to learn about something new, like PowerShell, so we can also say that we’ve broadened our knowledge by completing the above¬†ūüôā

First of all, I cannot take credit for the solution in this post. My thanks to the awesome guys over at iTG Technologies for researching and finding the fix for this.

If your organisation is on Office 365 and is still currently running Office 2013, then you may have noticed the following message has suddenly popped up on your Office programs recently:

Office2016UpgradeMessage

The bad news is that this message turns up of it’s own accord. This is not so much a problem if you are a home/single user, but could cause huge issues for enterprise IT departments who are holding off on upgrading due to add-in compatibility, not yet being able to test the applications themselves and problems with the computer environment itself (e.g. computers not meeting the minimum/recommended specifications).

The good news is that this error message can be disabled either via a Group Policy or by making the following change within the registry on the affected computers:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\15.0\common\officeupdate

Add the following value under the office update subkey:

“enableautomaticupgrade”=dword:00000000

Source: https://support.microsoft.com/en-us/kb/3097292

Whilst it is generally better to ensure you are on the latest versions of software, Office 2016 is still very early in its overall life-cycle and it makes prudent sense to delay rolling this out across organisations for a few more months at least.

Has anyone already upgraded or rolled out Office 2016 across their organisations yet? I would be interested in hearing your views/comments on how it is working for you.