Month: February 2013

Replacing ADFS 2.0 Secure Communications Certificate – “The Certificate Cannot Be Processed”

Posted on Updated on

For all Office 365 Active Directory Federation Services (ADFS) administrators, you may find that your ADFS “Secure Communications” certificate has expired and needs to be replaced or you need to replace the certificate and having issues replacing.  Many times administrators will start with an internal Certificate Authority (CA) cert and later upgrade to a public certificate, in order to support users with Outlook or other rich applications.

Whatever the reason, there are a few things you need to think about when performing this task:

  1. The Active Directory Federation Services MMC (UI) can be used to set the “Secure Communications” certificate by doing the following:
    1. Expand the ADFS –> Service –> Certificates node and right-click the certificates folder and select: Set Service Communications certificate option, which sets the certificate applied to your IIS default website as the secure communications certificate for use in ADFS.
      1. Note – You will be presented with all viable certificates in the Local Machine –> Personal –> Certificates store.
    2. Select the proper certificate presented and click OK

Note – I attempted this in my lab environment, however I had to rekey my certificate and the old certificate had been revoked.  Because of this, I believe the above steps failed with the following error, which forced me to use PowerShell to set the proper certificate while clearing out my old certificate.

Attempt to Set Secure Communications Certificate


Steps to Resolve

  1. Remove the old certificate from the Local Machine –> Personal –> Certificates store
  2. Import new certificate using IIS –> Import Certificate
    1. Place into the Local Machine –> Personal –> Certificate store
  3. Manage Certificates –> Manage Private Keys –> Grant read (I gave the ADFS AppPool identity Full Access)
  4. Launch PowerShell
    1. Add-PSSnapin Microsoft.ADFS.PowerShell
    2. Set-ADFSCertificate –CertificateType Secure-Communications –Thumbprint “e3 r 45 d4 5t 7u 8i 3e”
      1. Note:  Turns out the –CertificateType string is NOT enclosed in quotations while –Thumbprint is.  I had this backwards and the error states that “-CertificateTYpe is invalid”.  This is wrong, it was which string was wrapped in quotes.
          • Error Message if you enclose the wrong string in quotations:
            1. adfs_invalid_certType
        1. Example using PowerShell 3.0 ISE, which is an outstanding tool for working in PowerShell
          • set-secure_communications-success
  5. Restart IIS and ADFS Services
    1. IISReset
    2. ADFS 2.0 Service Restart
  6. Launch the ADFS 2.0 MMC –> Services –> Certificates and verify that the new certificate is listed
  7. Launch the Microsoft Online Windows PowerShell and update the Microsoft Federation Gateway with the new certificate and thumbprint
    1. Download and install Online PowerShell:
    2. Launch and connect to Microsoft Online Services:  connect-MSOLService
      1. Note: Enter your online Global Admin credentials
    3. Update MFG with new certificate information:
      1. Update-MSOLFederatedDomain -DomainName <>
    4. Check that the new certificate information, such as Thumbprint has been uploaded into the cloud:
      1. Get-MSOLFederationProperty -DomainName <>

AND TEST…you should be set and ready to go!

Lync Online Client Authentication Explained

Posted on

lync-online_h_rgb  For Lync Online Users and Administrators, you have found that your Session Initiation Protocol (SIP) sign-in address is required, such as along with login information which is typically the same User Principal Name (UPN) Fully Qualified Domain Name (FQDN), such as along with password.  What many users and administrators don know is that during this login process by the Lync Client, the Lync Online Service generates and gives the logged on user an online end-user personal certificate, which is used as part of the authentication and connection process.

Note – This end-user certificate can be found within IE –> Tools –> Content –> Certificates –> Personal location.  This certificate has a 180 day expiration and is required as part of the connection and authentication process.  Any Online/On-Premises administrators who run a “tight ship” in regards to whether users can be granted personal certificates, need to keep this online certificate requirement in mind and not block this process, otherwise the Lync client will not be able to login to the Lync Online Services.

Login & Connection Requirements

  1. Sip Login Name
    1. i.e.
  2. Username & Password
    1. User: i.e.
    2. Pass: password
  3. Ability to download and use the online user personal certificate
    1. Found in the following location, with a TTL (Time to Live) of 180 days
      1. IE –> Tools –> Content –> Certificates –> Personal

Office 365 Outbound Mail Deferrals

Posted on Updated on

exchange_online_banner_sm  For those Office 365 Exchange Online Administrators, who deal with day-to-day Email/Messaging management, you may find from time to time that outbound emails from users in your Office 365 tenant are not being delivered to outside (non-Office 365 recipients) recipients. There are many reasons for this, which could include:

  1. Incorrect Email Address
  2. Disabled/Removed Mailbox
  3. Downed Recipient Email Server
  4. 3rd Party Desktop Anti-Virus/Malware Software
  5. *** 3rd Party Mail Solutions, such as Positini, IronPort, etc

*** When 3rd party mail messaging solutions are in place, which interact with inbound/outbound mail items as they are sent/received between an on-premises mail server environment and Exchange Online, additional configurations are many times needed in order to properly work (i.e. scan and deliver mail messages). Many 3rd party mail messaging solutions have a configuration setting to “allow” certain IP addresses and/or Fully Qualified Domain Names (FQDN) to be entered, allowing or denying communication with these.

Note – If you are receiving Deferrals, shown in your Exchange Online Forefront Online Protection for Exchange (FOPE), this means that the receiving mail server has responded to an Exchange Online Mail Server, attempting to deliver a message, however the 3rd party device did not outright reject the message.  This directs EXO to queue the message and retry the message delivery at a later time (i.e. every ~5 minutes).  In this scenario, you should review your 3rd party mail management solution and determine IF it is set for Allow/Deny and if enabled, verify that all known Exchange Online IP addresses and/or FQDNs are defined, so the 3rd party mail management device can/will receive messages from the Exchange Online environment.

EXO IP & FQDN Namespaces

Attempting to Convert Office 365 Domain to Federated May Result In: Microsoft.Online.Administration.Automation.IdentityInternalServiceException

Posted on


When an Office 365 administrator attempts to convert their Office 365 “Managed” Domain, with user credentials stored in the cloud, to Federated, where authentication and credentials are stored in an on-premises Active Directory, you may run into the following error:

Convert-MSOLDomainToFederated : Microsoft.Online.Administration.Automation.IdentityInternalServiceException

At line:1 char:30

+ Convert-MSOLDomainToFederated <<<<

+ CategoryInfo : notSpecified: (:) [Convert-MSOLDomainToFederated]

, FederationException

+ FullyQualifiedErrorId: Microsoft.Online.Administration.Automatition.IdentityInternetServiceException, Microsoft.Online.Identity.Federation.PowerShell.ConvertDomainToFederated


Possible Reason

Administrators may have modified the PasswordExpirationPolicy, which defines how long online user passwords can exist before being forced to change the password.  However, the maximum setting for this is 720 and if this setting is > 720, you will hit this error!


  1. Change the Online Tenant’s PasswordExpirationPolicy to something less than 720, using the following PowerShell command(s)
    1. Install and Connect to Office 365 via Windows PowerShell for Online Services:
      1. Login using an online tenant Global Administrator
  2. Run the following PowerShell Command
    1. C:\PS>Set-MsolPasswordPolicy -ValidityPeriod 90 -NotificationDays 14 -DomainName
      1. Note – This command updates the policy on the domain so that users passwords will expire after 60 days and that the users will receive notification of 14 days prior to expiration.
  3. Once the PasswordExpirationPolicy has been updated, wait ~20 minutes, then attempt to convert the Managed Domain to Federated, using the following:
    1. Convert-MsolDomainToFederated -DomainName -SupportMultipleDomain
      1. Note – Only use -SupportMultipleDomain IF you need to support separate/different/distinct UPN namespaces, such as & You will need to run the above command twice, each time for the different domain namespace with the -SupportMultipleDomain parameter.