Pages

Saturday, December 31, 2016

You’ve noticed that the Skype for Business Server Access Edge service on your Skype for Business Server 2015 Edge server is stopped and the following error is thrown when you attempt to start it:

Windows could not start the Skype for Business Server Access Edge on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to the service-specific error code -2146762487.

Reviewing the event log displays the following errors:

Log Name: System

Source: Service Control Manager

Event ID: 7031

Level: Error

The Skype for Business Server Access Edge service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 180000 milliseconds: Restart the service.

Log Name: System

Source: Service Control Manager

Event ID: 7024

Level: Error

The Skype for Business Server Access Edge service terminated with service-specific error %%-2146762487.

Log Name: Lync Server

Source: LS Server

Event ID: 12303

Level: Error

The protocol stack reported a critical error: code 0x800B0109 (Configuration failure prevented the server from starting up). The service has to stop.

Log Name: Lync Server

Source: LS Server

Event ID: 12303

Level: Error

The protocol stack reported a critical error: code 0x800B0109 (CERT_E_UNTRUSTEDROOT). The service has to stop.

Log Name: Lync Server

Source: LS Protocol Stack

Event ID: 14623

Level: Error

A serious problem related to certificates is preventing Skype for Business Server from functioning.

Unable to use the certificate configured for the external edge of the Access Edge Server.

Error 0x800B0109(CERT_E_UNTRUSTEDROOT).

The certificate may have been deleted or may be invalid, or permissions are not set correctly.

Ensure that a valid certificate is present in the local computer certificate store. Also ensure that the server has sufficient privileges to access the store.

Cause: The Skype for Business Server failed to initialize with the configured certificate.

Resolution:

Review and correct the certificate configuration, then start the service again.

Log Name: Lync Server

Source: LS Protocol Stack

Event ID: 14397

Level: Error

A configured certificate could not be loaded from store. The serial number is attached for reference.

Extended Error Code: 0x800B0109(CERT_E_UNTRUSTEDROOT).

Clicking on the Details tab show the following:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

- <System>

<Provider Name="LS Protocol Stack" />

<EventID Qualifiers="33769">14397</EventID>

<Level>3</Level>

<Task>1001</Task>

<Keywords>0x80000000000000</Keywords>

<TimeCreated SystemTime="2016-12-30T01:27:45.000000000Z" />

<EventRecordID>154713</EventRecordID>

<Channel>Lync Server</Channel>

<Computer>svr-edge-01.ccs.int</Computer>

<Security />

</System>

- <EventData>

<Data>0x800B0109(CERT_E_UNTRUSTEDROOT)</Data>

<Binary>A6AC495DE63987EAE958F6506F58377D</Binary>

</EventData>

</Event>

One of the first troubleshooting steps I attempted was from the following blog post:

Attempting to follow the instructions provided by this blog post does not apply to your situation:

As I’ve come across a similar problem in the past, I sort of had a feeling that this had to do with a certificate that was missing from the intermediate or root store of the Edge server. To determine this, open the Certification Path of the certificate being used for the Edge interface:

Note that the issuing Certificate Authorities are:

GeoTrust Global CA

RapidSSL SHA256 CA

In this environment, the Root certificate GeoTrust Global CA was already in the Trusted Root CertificationAuthorities but the RapidSSL SHA256 CA was not in the Intermediate Certification Authorities:

Friday, December 30, 2016

You’ve noticed that a newly created user account in your on premise Active Directory is not showing up in your Office 365 Admin center so you review the Operations menu in the Synchronization Service Manager and notice that the export job displays the error InvalidSoftMatch in the Export Errors window pane:

Opening the InvalidSoftMatch entry brings up the following Connector Space ObjectProperties Pending Export tab with information confirming that this is the missing user account:

Continuing to click on the Export Error tab displays the following information with a Detail button:

Clicking on the Detail button will display the following Error Information:

Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:crussell@Contoso.com,smtp:crussell@ContosoReAG.mail.onmicrosoft.com,Mail crussell@Contoso.com;]. Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.

Tracking Id: 466344fe-a7c5-403e-8b0a-8621752ac178

You attempt to use the following PowerShell cmdlets via the WAAD (Windows Azure Active Directory) console to determine whether there is another account with the same smtp address:

All alias values in Office 365 must be unique for a given organization. Even if you have multiple unique suffixes after the at sign (@) in the Simple Mail Transfer Protocol (SMTP) address, all alias values must be unique.

Knowing that the user of the user account in question also had a pre-existing contact with an external SMTP email address, I began reviewing the properties of the existing contact in the Admin center:

Proceeded to click on the Edit Exchange settings link:

Which brought me to the Office 365 Exchange console of the contact object and it immediately became obvious that the problem was caused by the Alias of the exist contact (also configured as crussell):

Attempting to change the Alias would fail with:

error

The action ‘Set-MailContact’, ‘Alias,EmailAddresses’, can’t be performed on the object ‘Craig Russell’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

Attempting to delete the mail contact would throw the following error:

error

The action ‘Remove-MailContact’, ‘Identity’, can’t be performed on the object ‘Craig Russell’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

Having no luck with the GUI, I proceeded to review the Remove-MsolContact cmdlet:

Thursday, December 29, 2016

I’ve noticed that many of my clients have noticed that the GoToMeeting, GoToWebinar and GoToTraining icons can mysteriously appear when using the Citrix Receiver to connect to applications after upgrading their XenApp or XenDesktop from, say 7.6 to 7.11:

Administrators will know that earlier versions of StoreFront allowed you to disable these icons by clicking on Stores then the Integrate withCitrix Online link on the right but later versions have now removed this option. To disable the icons shown above, navigate to Configure Store Settings:

Wednesday, December 21, 2016

I’ve been recently involved with a project where I had to assist a client with a Exchange 2010 to 2016 migration and one of the tasks I was assigned to do was to migrate the existing Exchange 2010 Servers receive connectors to the new Exchange 2016 servers:

I’ve come across this quite a few times in the past and even wrote a blog post 6 years ago:

I did a bit of troubleshooting and searching but could not find a solution so decided to fall back on the same approach in my older blog post using native Exchange PowerShell cmdlets and a bit of editing of the information in notepad.

Before I begin demonstrating the PowerShell cmdlet and switches to use, let’s begin by reviewing the parameters we’ll be configuring for a receive connector by looking at the options in the EAC:

General Options

Note that the parameters available to be configured in the screenshot above are:

Name

Connector status

Protocol logging level

Maximum receive message size (MB)

Maximum local hop count

Maximum hop count

These parameters map to the following PowerShell switches:

Parameter

Switch

Name

Name

Connector status

Enabled

Protocol logging level

ProtocolLoggingLevel

Maximum receive message size (MB)

MaxMessageSize

Maximum local hop count

MaxLocalHopCount

Maximum hop count

MaxHopCount

Security Options

Note that the parameters available to be configured in the screenshot above are:

Authentication

Permission Groups

These parameters map to the following PowerShell switches:

Parameter

Switch

Options

Authentication

AuthMechanism

Transport Layer Security (TLS)

Enable domain security (mutual Auth TLS)

Basic authentication

Offer basic authentication only after starting TLS

Integrated Windows authentication

Externally secured (for example, with IPsec)

Permission Groups

PermissionGroups

Exchange servers

Legacy Exchange servers

PartnersExchange users

Anonymous users

Scoping Options

Note that the parameters available to be configured in the screenshot above are:

Remote network settings

Network adapter bindings

FQDN

These parameters map to the following PowerShell switches:

Parameter

Switch

Remote network settings

RemoteIPRanges

Network adapter bindings

Bindings

FQDN

FQDN

Step #1 – Retrieve and Export Receive Connector Configuration

With the configuration parameters outlined above, the first step for migrating the receive connectors to the new Exchange server is to use the Get-ReceiveConnector to export the receive connectors’ information. The following is the cmdlet with the switches required:

Notice that the RemoteIPRanges configuration output gets truncated when the list has more than 16 entries which means if the list has less than 16, you’re set to go but if you have more then you’ll have to execute the following before using the Get-ReceiveConnect cmdlet:

You’ve recently failed over the CMS and pool from a primary Skype for Business Server 2015 to a backup server then failed the services back to the primary server but started noticing the following errors logged on the primary active server with the contents referencing the backup server:

Log Name: Lync Server

Source: LS Backup Service

Event ID: 4098

Level: Error

Skype for Business Server 2015, Backup Service central management backup module has backup data that never gets imported by backup pool.

Backup data file: \\drlyncstd01.domain.com\LyncShare\2-BackupService-1\BackupStore\CentralMgmt\CMSMaster\Data\Backup.zipCause: Import issue in the backup pool. Please check event log of Skype for Business Server 2015, Backup Service in the backup pool for more information.Resolution:Fix import issue in the backup pool

Note that the content in the error log references the backup / disaster recovery server but the event is logged on the primary active server.

The backup / disaster recovery server also has the Skype for Business Server Master Replicator Agent service stopped. You can start the service but it will stop after a few minutes:

Solution

I’ve noticed this happening in most SfB environments that have experienced a planned or unplanned failover of the CMS and/or pool. To correct the issue, simply launch the Skype for Business Server 2015 – Deployment Wizard on the backup / disaster recovery server, navigate into the Install or Update Skype for Business Server System menu:

… and then run both the:

Install Local Configuration Store

Setup or Remove Skype for Business Server Components

Once the above have successfully completed, the Skype for Business Server Master Replicator Agent service should now start and stay running: