Recipient type Permission Removal

I wonder if anyone out there has had some issues when they have applied ‘Send-On-Behalf‘ or ‘SendAs‘ permissions with powershell  or on the ECP?

What issues … well considering you are using one of the versions of DirSync/AAD Sync & you apply thee permissions to an account  & then later delete  the account in the AD; have you experienced that even after a sync runs one of the two permissions are still there?

Well, with the ‘Send-On-Behalf‘  Microsoft considers it a feature. AS a safe-gaurd in case someone is accidentally deleted or had a license removed. Some feature ! And it creates another problem. Well, the problem is that if a deleted is still appearing then you’ll get an error when trying to add more to the list. Luckily, the solution is fairly simple for  ‘Send-On-Behalf‘ .  If you from powershell or ECP you should still be able to remove the account. Then advise your customers to add these rights in the AD under ‘publicDelegates‘ .As I rule I highly recommend not using ‘Send-On-Behalf‘ rights & most certainly never mix the 2 rights. As then they won’t function properly. ‘Send-On-Behalf‘ is  a delegation right & usually when applying it a delegation is created and a person that has these rights may see some weird behavior such as getting updates when a person make a calendar change or accepts an appointment. But if you still need to apply ‘Send-On-Behalf‘ rights do it in the AD under ‘publicDelegates‘. Now, I originally experienced this about 2 years ago & I already pointed out MS’s response.  Since then until lately; it actually seemed that the issue was actually cleared up. But it has reared its ugly head again. So, you know how to fix it now.

Now the issue with ‘SendAs‘ permissions is nearly identical as the one described above but the solution is a little more complicated. As you won’t be able to remove the user on the ECP . You will get an  error like above that the ‘object can’t be found‘. If you go to powershell ; you’ll also likely get an error there if you were to use the UPN or PrimarySMTP . What you need to do is go to the mailbox where the permission is applied & run:

Get-Recipientpermission -identity |select Trustee,Accessrights

You’ll receive a list of users and find the one with the ‘SendAs‘ rights. it may appear as: EUROPROD5\john541622091

What you’ll notice is the identity for the deleted account has changed as it now references an identity in a soft-deleted db. So,now you have the accounts new identity and then can remove it with everything after the  slash:

Remove-Recipientpermission -identity -trustee john541622091

This will remove the account from having ‘SendAs‘ permissions  & in the future for the same account if the account is recovered.





Image Upload

In order to add a profile image to a user account:
Your photo cannot be larger than 10 KB with a max of 96×96 and it must use one of the following file extensions: .jpg , .gif , .png or bmp and added to the ‘thumbnailPhoto’ attribute in the AD. Many use ‘CodeTwo Active Directory Photo’ for uploading the image. Be aware that it can take more than 72 hours for the image to be updated after adding it to the AD.

In Office 365:

Set-UserPhoto -Identity “briangrantmust@proactive.local” -PictureData ([System.IO.File]::ReadAllBytes($photo)) -Confirm:$false

In AD:

Set-ADUser –Identity btgrant -Replace @{thumbnailPhoto=([byte[]](Get-Content “C:\photos\btg.jpg” -Encoding byte))}

You can use a photo from your computer or from a network share that’s linked to your computer. You can use a photo or other image that’s up to 500 kilobytes (KB) in size.

From OWA:

Cog Wheel >Office 365 Settings>Personal Info>Hover mouse over image>Change Photo>Browse>Upload & Save


Certificate Rollover

For those of you that are still running Active Directory Federation Services 2.0 & your Token-decrypting and Token-signing certificates are about to expire ;if you have the  default settings , a new certificate is automatically generated 20 days before each certificate expires you can renew it 20 days before & you can do this manually .

Update-MsolFederatedDomain –domainname <domain name>

But Microsoft has a great script that can be run that will create a scheduled task running once a day that will switch them over automatically.

For those that are using Relying-party Trusts like Yammer ; you will need to export the public key portion of a token-signing certificate ; attaching it to a service request & this should be done no less than 14 days before the switch over date.  I heard this process may change & will keep you updated.  But the exporting process is listed below:

To export the public key portion of a token-signing certificate

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.
  2. Right-click Federation Service, and then click Properties.
  3. On the General tab, under Token-signing certificate, click View.
  4. In the Certificate dialog box, click the Details tab.
  5. On the Details tab, click Copy to File.
  6. On the Welcome to the Certificate Export Wizard page, click Next.
  7. On the Export Private Key page, make sure that No, do not export the private key is selected, and then click Next.
  8. On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next.
  9. On the File to Export page, specify the certificate file in File name, and then click Next.

MDM and Intune

Microsoft has launched earlier this year MDM management . But what if you want to use MDM  & Intune. Now they both can exist on your Office 365 tenant. I have been running this since late August on my test tenant.  the advantage is that you are setting two SOA (source of authorities) by doing half the work per say but it is an easy way to bypass making exceptions for users that are still using ActiveSync connections & then other users or Admins want to manage their users with Intune.

You find my original thoughts in the Community Forum