This post has been republished via RSS; it originally appeared at: Skype for Business Blog articles.
First published on TECHNET on Feb 14, 2017Author: Sri Todi , Microsoft Support Escalation Engineer
When the ExchangeArchivingPolicy (commandlet: Get-csUser) is set to UNINITIALIZED, Skype for Business Server 2015 is designed to first connect to Exchange to verify, if the mailbox has an in-place (or Litigation) hold. If a In-Place (or litigation hold) is active, archiving is done in Exchange, else Archiving is performed on Skype for Business Server 2015 / Lync Server 2013 Archiving Database (DBName: LCSLog).
Cause:
In-order for content logging to occur when ExchangeArchivingPolicy is set to UNINITIALIZED for a user, the following should be set-up correctly
- Exchange Auto-Discover ( DNS, Certificates and connectivity from Skype for Business Server 2015 Pools)
- OAuth Certificates ( Both in Skype for Business Server 2015 environment and Exchange Server Environment need to have the certificate imported)
- Trusted Application Partner Relationship between Exchange Server Environment and Skype for Business Server Environment
References:
- Manage server-to-server authentication (OAuth) and partner applications in Skype for Business Server 2015
- Assign a server-to-server authentication certificate for Skype for Business Server 2015
- Configure Skype for Business Server 2015 in a hybrid environment
- Configure an on-premises partner application for Skype for Business Server 2015
- Configure OAuth between Skype for Business Server and Exchange Online
- Configure a cross-premises environment in Skype for Business Server 2015
When the above mentioned pre-requisites are configured correctly and are working as intended; we will see a successful connection to Exchange, query to ensure that the mailbox doesn't have an in-place hold, then and only then, will the Skype for Business 2015 service determine that the Archiving should be done on a Lync / Skype for Business Archiving Server. If an in-place hold is found on the mailbox, the archiving will be conducted on Exchange Server.
If a connection cannot successfully established then, the connection is retried, until a successful connection is established.
Test-CsExStorageConnectivity
can be used to verify successful connection between Exchange and Lync/Skype for Business.
If the configuration wasn't working as intended, say because of an expired certificate or missing configuration, the messages are queued up on each Front-End Server, in the LYSS database (Database Instance LYNCLOCAL), to be committed when a connection to Exchange Server is successful.
Resolution: Ensure that the Pre-requisites are configured correctly
- Exchange Auto-Discover ( DNS, Certificates and connectivity from Skype for Business Server 2015 Pools)
- OAuth Certificates ( Both in Skype for Business Server 2015 environment and Exchange Server Environment)
- Trusted Application Partner Relationship between Exchange Server Environment and Skype for Business Server Environment
- Run Test-CsExStorageConnectivity , to verify successful connectivity
Once the connection is successful, for every user Exchange will be queried to verify if an in-place hold exists, and if it does, the messages will be archived in Exchange, otherwise, they will be archived on Lync / Skype for Business Servers
Work-Around:
One work-around is to prevent Exchange from being contacted, and writing all messages directly to the archiving server for Lync/ Skype for Business. In-order to do so, you will have to perform the following
-
Configure all users with the ExchangeArchivingPolicy to use UseLyncArchivingPolicy. This can be established by running
Get-CsUser | Where-Object {$_.ExchangeArchivingPolicy -ne “UseLyncArchivingPolicy”} |Set-CsUser -ExchangeArchivingPolicy UseLyncArchivingPolicy
- Update your User provisioning scripts, to ensure that the ExchangeArchivingPolicy is configured to be UseLyncArchivingPolicy for all new users.
Note : This work-around will cause all newly created archiving content to be sent to Lync/ Skype for Business Server Archiving Server Role.
Since Archiving is a compliance / regulatory requirement, organizations may want all the data, currently in queue to be sent to Archiving Server role in Lync/Skype for Business. In-order to do so, you will have to run a script on every Front-End Server in the environment, to tag, older messages ( messages when ExchangeArchivingPolicy was not set to UseLyncArchivingPolicy).
Before the script is run, please ensure to take Full-Backups of your Skype for Business 2015 Server, and to ensure that you also have taken backups of all your databases ( Front-End, Back-End, Monitoring, Archiving, CMS etc..)
NOTE: Caution should also be exercised , as the script can cause messages from several days ( or even months) that have been queued-up to be committed, thereby increasing, CPU and Disk Utilization both in the Front-End Pool and the Archiving Server. Also since the data will be transmitted over the wire, you can see significantly increased network traffic.
Use Lyss
Go
set nocount on
-- do not process archiving data while we reroute
insert AdapterSkip select 'CDE2BACE-F515-444D-A3F1-858A7FC8728F', 'reroute data to legacy archiving', getutcdate()
where not exists (select top (1) 1 from AdapterSkip where AdapterID = 'CDE2BACE-F515-444D-A3F1-858A7FC8728F')
insert AdapterSkip select '00606210-86E4-41DC-BCD9-0808C0AF1897', 'reroute data to legacy archiving', getutcdate()
where not exists (select top (1) 1 from AdapterSkip where AdapterID = '00606210-86E4-41DC-BCD9-0808C0AF1897')
-- ensure in-flight data completes processing
waitfor delay '0:05:00'
-- reroute exchange archiving to legacy
begin try
begin transaction
update ItemEndpoint set AdapterID = '00606210-86E4-41DC-BCD9-0808C0AF1897'
where AdapterID = 'CDE2BACE-F515-444D-A3F1-858A7FC8728F'
print 'ItemEndpoint rows updated: ' + cast(@@ROWCOUNT as varchar)
update ItemQueue set AdapterID = '00606210-86E4-41DC-BCD9-0808C0AF1897'
where AdapterID = 'CDE2BACE-F515-444D-A3F1-858A7FC8728F'
print 'ItemQueue rows updated: ' + cast(@@ROWCOUNT as varchar)
print 'reroute succeeded'
commit
end try
begin catch
select 'reroute failed', 'Error:', ERROR_NUMBER(), 'Message', ERROR_MESSAGE()
rollback
end catch
-- re-enable archiving processing
delete AdapterSkip where AdapterID in ('00606210-86E4-41DC-BCD9-0808C0AF1897', 'CDE2BACE-F515-444D-A3F1-858A7FC8728F')
go
This script is expected to take atleast 5 minutes per Front-End Server, and should be run on one server in a pool at a time. Once the script execution has completed, you may move to the next server in the pool.
Finally, please wait for the CPU, Disk and Network utilization to come to normal values both on the Front-End Server and Archiving Servers. This can easily be upwards of 4 hours, depending on the amount of days, for which archiving data that needs to be committed. It is recommended, not to add load on the archiving server, especially if it's also your monitoring server, by generating reports.
It is highly recommended that you partner with Microsoft Support when running the script to ensure that they can help you, in-case you experience difficulties.