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 🙂

Header

When I first took a look at some of the additions I was looking forward to as part of the CRM 2016 Spring Wave, I made reference to the new Email Signature feature. At the time, there did not appear to be any way of accessing this via the GUI interface within CRM; this is despite the fact there were, clearly, new system entities in the system corresponding to Email Signatures. There appears to have been some small update or change since my original post however, as it is now available within Online/On-Premise 8.1 CRM instances 🙂 . To take advantage of the new feature depends on what version of CRM you are running:

Once you’ve finished updating, you are good to go. To then setup an Email Signature for your user account, you will need to do the following:

  1.  Navigate to the Email Signature window within CRM. This can be accessed in either 1 of 2 ways:
    • The first is via the Set Personal Options screen, on the Email Signatures tab:1 2 3
    • The second is via the Sitemap Area, in Settings -> Templates -> Email Signatures:9 10
  2. Regardless of how you have got there, press the New button to open the New Email Signature window:154
  3. Give your signature a name and then populate the text area with your desired signature. You can make use of the rich text formatting in order to style your signature. Or, alternatively, you can copy & paste your signature from another application (Word, Outlook etc.):5
  4. Once you are happy with your signature, press Save. At this point, the signature will now be available whenever you create a new email record. However, in order to make the signature appear automatically whenever you draft a new email, you will need to press the Set as Default button:6If you need to revert this at any point, then you can use the Remove Default button, which replaces the above button:7
  5. Press Save and Close to finish setting up your signature. It will now be visible within the Email Signature subgrid view:8 11
  6. Now, when you navigate to create a new Email record, your newly created signature will be visible on the email:12
  7. If, for whatever reason, you need to select a different Email Signature, then press the Insert Signature button, which will then prompt you to select a new Email Signature to use:1413

I am really glad that this feature has finally been added to CRM, however…

There appear to be three glaring issues, that really need to be addressed in order to make Email Signatures work better:

  • Email Signatures are only configurable on a per-user basis. What that translates to is that if one user creates an email signature and sets it as their default, another user can log in and see this, but cannot apply it to themselves or set it as their default; if the second user wanted an email signature, they would need to create one manually. The implications for this should be fairly obvious, and I find it somewhat confusing that there is not way to setup a common template that can be then be applied and customised individually for each user on CRM.
  • There is no option, unlike Email Templates, to insert dynamic Data Field Values. So you cannot, for example, populate an e-mail signature based on information from the Job Title field on the currently logged in User account. This makes the feature impractical as a central Email Signature management tool; instead, you would have to go through the potentially rather tedious task of setting up Email Signatures for every user account on a system. Not so bad if you have a dozen or so users on your CRM instance, but if you have hundreds of users…you get the point.
  • Whilst recently studying for the CRM 2016 Service exam, I was really impressed to see that the Knowledge Article feature had been given a face lift in line with the new Interactive Service Dashboard. In particular, the text editing functionality has been improved significantly, with a range of new text editing options – many of which are not included as part of creating an Email Signature. Below is an image highlighting each of the new text editing features not available on Email Signatures, but available as part of the enhanced Knowledge Article functionality:16As you can see, there are a number options as part of the above which would be incredibly useful from a Email Signature creation point of view – Insert Image, Font Colour and View Source (perhaps the most crucial, if your organisation uses HTML signatures). I wonder why, therefore, the new Email Signature feature was not modeled in the same vein as the above.

Conclusions

Previously, in an attempt to replicate email signature functionality, the recommended approach was to setup an Email Template. This is beneficial when it comes to larger CRM deployments, as the dynamic data fields functionality can be utilised when creating a common template. The introduction of the new Email Signature functionality does not, in my view, mean there should be a change to this approach. I think if your CRM deployment contains a small amount of users and you have a very simplistic, existing email signature, then you can perhaps get away with using this new feature without causing yourself too many problems. Until the above issues are addressed however, I would not recommend migrating away from what you are using currently to provide email signature functionality within your CRM. This is a real shame, as I was hoping the introduction of this feature would resolve some of the headaches that I have encountered previously working with complex email signatures in CRM. Fingers cross we see Email Signatures get a bit more love and attention as part of the next major release of CRM.

The current talk around CRM at the moment is all about the Spring Wave AKA the CRM 2016 Update 1. Unlike Dynamics CRM 2015 Update 1, released at the same time last year, On-Premise customers can also take advantage of the latest update now by downloading Service Pack 1. Now it’s worth pointing out that some features, such as Guided Help and Field Service Management, are not made available to On-Premise customers at this time. Nevertheless, I think it’s a really positive step forward that On-Premise customers get most, if not all, of the latest updates as part of the Spring Wave, at the same time as Online customers. I’ve already talked previously about some of the great things to expect as part of the Spring Wave, so I would strongly recommend that organisations look at scheduling in their on-premise upgrade sooner rather than later. The main reason is the simplicity involved behind the actual upgrade process, which is the focus for this week’s blog post:

How to Download Service Pack 1

If you have enrolled your Dynamics CRM installation into Windows Update, then currently SP1 does not appear when your run Check for Updates on your CRM Server (this will change starting from Q3, according this knowledgebase article). Therefore, you will need to download the update manually via the following link:

https://www.microsoft.com/en-us/download/details.aspx?id=52662

There are a number of install files available as part of the update. On first glance, it can be difficult to determine which update file relates to which component of your CRM installation, so I have provided a summary of this below:

CRM2016-Client-KB3154952-ENU-Amd64.exe – Outlook Client (64 Bit)
CRM2016-Client-KB3154952-ENU-I386.exe – Outlook Client (32 Bit)
CRM2016-Mui-KB3154952-ENU-Amd64.exe – Outlook Client (64 Bit) Language Pack – English
CRM2016-Mui-KB3154952-ENU-I386.exe – Outlook Client (32 Bit) Language Pack – English
CRM2016-Router-KB3154952-ENU-Amd64.exe –  Email Router (64 Bit)
CRM2016-Router-KB3154952-ENU-I386.exe – Email Router (32 Bit)
CRM2016-Server-KB3154952-ENU-Amd64.exe – Server Update
CRM2016-Srs-KB3154952-ENU-Amd64.exe – Reporting Extensions

There is also a final file – CRM2016-Tools-KB3154952-ENU-amd64.exe – which I believe may be some kind of utility to perform database upgrades. I have been unable to get this working successfully on my end and, from the looks it, the server update performs the database upgrade as part of the update. If anyone knows what this is for and how it works, let me know in the comments below.

Installing the Update

The update is really simple – this is backed up by the fact that it can be completed in as little as 6 button presses!

After running the self-extracting installer, you will be greeted with the first screen of the setup process:

SP1_Update_1

As is always the case, accept the license agreement:

SP1_Update_2

Then, confirm that you are ready to begin the installation:

SP1_Update_3

The installation process shouldn’t take long (about 10 -15 minutes when I performed it). Once complete, you’ll then be able to view the installation log file and specify whether or not you want to restart the server immediately:

SP1_Update_4

 

As part of the update, your organisations and databases will be automatically updated to the latest version. So, no need to manually perform this yourself after the update.

Reporting Extensions Update

The only thing to point out with this is that this will need to be installed on the same machine as your CRM’s SSRS instance. Depending on your On-Premise deployment, your SSRS instance may be installed on a different server. The actual process of installing the update is identical to the above. Fortunately, however, a server reboot is not required 🙂

Outlook Client Update

Updating the Outlook client is also very similar and straightforward. Any existing connections will still work after the update. You will also need to install the update(s) for any currently installed language pack(s) immediately after this update is complete. In most cases, this will just be the one update for your CRM organization’s base language. Depending on the size and complexity of your CRM deployment, you may need to plan carefully to ensure a successful roll-out; you may be happy to note that the existing CRM client should still work with a 8.1 CRM instance, so you can always choose to defer this part of the update entirely.

The Testing Conundrum

As with any application update, it is always prudent to ensure that you have performed some kind of testing. This can be invaluable in identifying issues that can then be resolved in good time, without causing disruption to colleagues/end-users of the application.

The difficulty in this particular case is that the update appears to automatically update all organizations on a CRM instance in one fell swoop. So you cannot, for example, setup a copy of your primary CRM instance that you can perform a test upgrade on. You would therefore have to deploy an entirely separate CRM instance which you can perform the necessary testing on. You can use a trial key to cover the initial licensing hurdle, but you will still need to allocate hardware and put time aside to get your temporary testing environment setup.

Given that this release is not a “major” release of the application, I would argue softly that you can probably throw caution to the wind and perform the update with a minimal amount of testing, particularly if your CRM instance has not been significantly customised/extended. There does not appear to be anything majorly changed under the hood of CRM for this release that could cause problems (unlike the 2015 Spring Wave release for CRM Online). In order to best inform your decision on this, you should consider the following factors:

  • Are you able to schedule your CRM update over a weekend or extended out of hours slot, and have resources in place to perform any post-update testing? If the answer is yes, then you may be able to get away with not performing any pre-update testing.
  • What is the maximum amount of time your CRM instance can be taken down for during normal working hours?
  • Does your CRM utilise the Email Router, CRM for Outlook and/or multiple language packs? If yes, then performing upgrade testing of these components may be beneficial.
  • Does your business have a spare Windows Server instance that can be used for a test upgrade, without incurring additional cost to the business? If yes, then a major impediment has been eliminated, meaning that you should look at performing a test update.

Has anyone performed an On-Premise upgrade to SP1 yet? Let me know your experience and comments below!

As part of a recent project I have been involved in, one of the requirements was to facilitate a bulk data import process via a single import spreadsheet, which would then create several different CRM Entity records at once. I was already aware of the Bulk Data Import feature within CRM, and the ability to create pre-defined data maps via the GUI interface; what I wasn’t aware of was that there is also a means of creating the very same data maps via the SDK or an .xml import. This was a pleasant surprise to say the least and, from the looks of it online, there is very little in the way of resource available for what is, arguably, a very powerful out of the box feature within Dynamics CRM. Expect a future blog post from me that dives a bit deeper into this subject, as I think the capabilities of this tool could fit a variety of differing requirements; if only the instructions within the SDK were a bit more clearer when it comes to  working with the raw data map .xml!

Whilst attempting to perform a proof of concept test, I uploaded a data map .xml into CRM, which contained references to four different entities. When I then attempted to run the data import using a test file, I encountered a strange issue which meant I could not proceed with the import. This occurred when CRM attempted to map the record types specified as part of the data map:

DataMap_Error

Can you spot the two issues?

The first, more obvious, problem is the yellow triangle on the 3rd entity option and the fact that the Record Type is empty. Whereas the 3 other options will display clearly the Display Names of the entities (e.g. Account, Lead), the Display Name of the problematic entity is not visible at all.

The more eagle-eyed readers may also have spotted the second, more serious issue; the next button is grayed out, meaning we have no way in which to move to next step as part of the data import. With no means of figuring out, exactly, what may be causing the problem based on the above screen, you can potentially expect a long-haul investigation to commence.

As it turns out, the issue was both simple and frustrating in equal measures. It turns out that because the third entity on the list of the above had the exact same Display Name value as another entity within the system, CRM got confused and was unable to display and map with the correct entity. So, for example, lets say you create a custom entity to record information relating to houses, called “Property”, with a Name of “new_property”. Without perhaps realising, CRM already has a system entity called “Property”, with a Name of “dynamicproperty”. It doesn’t matter that the Names of the entities are completely different; so long as the Display Names are, then you will encounter the same issue as highlighted above. So, after renaming the entity concerned with a unique Display Name (don’t forget to publish!), I was able to proceed successfully through the data import wizard.

So why is this frustrating? If, like me, you have worked with CRM for some time, your first assumption would be that the system would always rely on the Name of objects when it comes to determining unique entities, attributes etc. The above appears to be the exception to the rule, and is frustrating for the fact that it throws out of the window any assumed experience when it comes to working under the hood of CRM. Perhaps it was (fairly) assumed that, because the logical names must always be unique for entities, that the data map feature could just use the Display Name as opposed to Name when attempting to map record types. I would expect that CRM is performing some kind of query behind the scene at the above stage of the Data Import wizard, and that the Display Name field value is included as parameter for all entities included in the data map. In summary, I would suggest that this is a minor bug, but something that would be difficult to encounter as part of regular CRM use.

Hopefully the above post will help prevent anyone else from spending 6+ hours from figuring out just what in the hell is going on 🙂 As a final side note, what this problem and solution demonstrates is an excellent best practice lesson to avoid; be sure to provide distinct Display Names to your custom entities.