Configuring Content-Security-Policy HTTP Response Header on Citrix ADC for Citrix Apps and Desktops with DUO integration

I was recently asked to troubleshoot an issue where an administrator implemented the Content-Security-Policy HTTP Response Header on a Citrix ADC for Citrix Apps and Desktops with DUO integration and immediately noticed that users were no longer able to successfully log onto the portal. The following outlines the behavior and steps to remediate the issue.

**Note that more information about the Content Security Policy HTTP response header can be found in Scott Helme’s article at the following URL: https://scotthelme.co.uk/content-security-policy-an-introduction/

Problem

The following Rewrite, Policy and Binding was configured onto the Citrix ADC (formerly known as Citrix ADC) to secure the

add rewrite action rw_act_insert_Content_security_policy insert_http_header Content-Security-Policy "\"default-src \'self\' ; script-src \'self\' \'unsafe-inline\' \'unsafe-eval\' ; style-src \'self\' \'unsafe-inline\' \'unsafe-eval\'; img-src \'self\' data:\""

add rewrite policy rw_pol_insert_Content_security_policy "HTTP.RES.HEADER(\"Content-Security-Policy\").EXISTS.NOT" rw_act_insert_Content_security_policy

bind vpn vserver _XD_10.0.1.11_443 -policy rw_pol_insert_Content_security_policy -type RESPONSE -priority 160

The login page presented by the Citrix ADC displays and functions properly:

However, the 2FA authentication page that is supposed to present the DUO multifaction options for sending the user a push, call to their mobile or entering a password does not load as the redirect appears to fail:

Solution

The best way to troubleshoot such an issue when implementing the Content-Security-Policy HTTP Response Header on Citrix ADC is to switch the rewrite action to insert a Content-Security-Policy-Report-Only header instead of the Content-Security-Policy header as this would simply report the expected action and results rather than enforce them. To enable this feature, simply change the field from Content-Security-Policy to Content-Security-Policy-Report-Only as shown in the following screenshot:

With the reporting mode enabled, proceed to relaunch the Google Chrome browser, click on the horizontal ellipsis from the top right corner, select More Tools, then Developer tools (CTRL+SHIFT+I):

With the Developer tools window opened, select the Network tab, click on the ellipsis at the top right corner and select Show console drawer:

The Network tab will display all the resources that is loaded as you navigate through the portal and the console will output verbose details of the Content Security Policy being applied but will only report the results rather than enforce it. Note the output shown in the console:

The Content Security Policy 'default-src 'self' ; script-src 'self' 'unsafe-inline' 'unsafe-eval' ; style-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:' was delivered in report-only mode, but does not specify a 'report-uri'; the policy will have no effect. Please either add a 'report-uri' directive, or deliver the policy via the 'Content-Security-Policy' header.

Proceed to log into the portal to replicate the issue, and in the case of this example, the console will display the following output indicating why the DUO authentication webpage would have been blocked:

[Report Only] Refused to load the script 'https://api-01b56e27.duosecurity.com/frame/hosted/Duo-Citrix-NetScaler-RfWebUI-v1.js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' 'unsafe-eval' ". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

[Report Only] Refused to frame 'https://api-01b56e27.duosecurity.com/' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'frame-src' was not explicitly set, so 'default-src' is used as a fallback.

The report from above indicate the following directives we defined in our rewrite action are preventing the redirect of the DUO 2FA api-01b56e27.duosecurity.com page from being loaded: 

"default-src 'self' ; script-src 'self' 'unsafe-inline' 'unsafe-eval' ; style-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:"

To remediate the issue, simply modify the rewrite action as such to include the subdomains of the page the portal is attempting to redirect the user:

"default-src 'self' *.duosecurity.com ; script-src 'self' *.duosecurity.com 'unsafe-inline' 'unsafe-eval' ; style-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:"

Note that I opted to include all of the subdomains because I am unsure as to whether DUO would ever change the URL in the future but in the event where you are certain this URL will not change, it would be best to specify an exact match.

--------------------------------------------------------------------------------------------------------------------------

Update: April 26, 2020

As I wasn’t familiar with Duo deployments and had only recently been able to deploy the solution, I had that the hostname api-01b56e27.duosecurity.com is unique to the application Duo is protecting so the URL isn’t supposed to change as long as you do not remove and recreate the application in the Duo administration console. You can retrieve the URL in the Duo administration console shown in this screenshot:

--------------------------------------------------------------------------------------------------------------------------

With the changes made, proceed to relaunch the page to verify that the authentication page is no longer blocked and loads successfully:

… then change the Header Name for the rewrite action on the Citrix ADC from Content-Security-Policy-Report-Only back to Content-Security-Policy.

I hope this will help anyone who may experience a similar issue when securing their web applications to score an A at: https://securityheaders.com/

Confirming a Citrix ADC is CVE-2019-19781 vulnerable and compromised then proceeding to remediate

I took an extended leave from IT for most of 2009 until returning later in December and therefore haven’t had to deal with the Citrix CVE-2019-19781 vulnerability but I just so happened to come across an unpatched Citrix ADC the other day so I thought I’d go through the process as outlined by my friend Thomas Poppelgaard (https://www.poppelgaard.com/cve-2019-19781-what-you-should-know-and-how-to-fix-your-citrix-adc-access-gateway) in detail to capture and show some screenshots of what an exploited Citrix ADC would reveal during the tests as well as the remediation I performed at the end. I won’t be reiterating all the details about the tests so please refer to his blog post for a more in depth description of why and what the test are for.

Confirming Vulnerability and Compromise

CISA and Citrix both offer tools to check the Citrix ADC for the vulnerability:

CISA UTILITY TO CHECK IF CUSTOMER IS VULNERABLE

https://github.com/cisagov/check-cve-2019-19781

CVE-2019-19781 – VERIFICATION TOOL FROM CITRIX

https://support.citrix.com/article/CTX269180

… but a community tool created by zentura_cp is available on Azure to perform the check quickly. That tool can be found here: https://cve-2019-19781.azurewebsites.net

Scanning the Citrix ADC in this environment confirmed that it is vulnerable to CVE-2019-19781:

The wildcard certificate check did not reveal a match but I have recommended the client to revoke and reissue the certificate.

Checking the Template Files

As indicated by Thomas Pooelgaard’s article, the exploits all write files to the following three directories:

/netscaler/portal/templates/

/var/tmp/netscaler/portal/templates

/var/vpn/bookmark/

There is no need to switch to the shell prompt from the CLI as you can execute an ls on these directories as such:

shell ls /netscaler/portal/templates/*.xml

shell ls /var/tmp/netscaler/portal/templates

shell ls /var/vpn/bookmark/*.xml

Initiating a ls command for those directories return the following:

shell ls /netscaler/portal/templates/*.xml

> shell ls /netscaler/portal/templates/*.xml

/netscaler/portal/templates/02a81b35.xml

/netscaler/portal/templates/04c86902.xml

/netscaler/portal/templates/06fb0cee.xml

/netscaler/portal/templates/0bc583f8.xml

/netscaler/portal/templates/17EOk.xml

/netscaler/portal/templates/1Z5g92Aky.xml

/netscaler/portal/templates/1d9363f1.xml

/netscaler/portal/templates/2YMBK.xml

/netscaler/portal/templates/3QJW6.xml

/netscaler/portal/templates/3YDd6gheCtB8mrJL2zfyO4WKl7sG0MQa.xml

/netscaler/portal/templates/473ce5e1.xml

/netscaler/portal/templates/48ZwobXq0yjVtU3GeC2a95kBfAHNu1Qz.xml

/netscaler/portal/templates/4GgZh.xml

/netscaler/portal/templates/53963742.xml

/netscaler/portal/templates/5BdZA.xml

/netscaler/portal/templates/5qIJsMV1x9aUGzKirLuNtRYX032QjnvS.xml

/netscaler/portal/templates/5t4ls.xml

/netscaler/portal/templates/64c2192d.xml

/netscaler/portal/templates/6fef6135.xml

/netscaler/portal/templates/77bd07f9.xml

/netscaler/portal/templates/7BA1C.xml

/netscaler/portal/templates/7ESdi.xml

/netscaler/portal/templates/8HtqLVavu.xml

/netscaler/portal/templates/8W7Cgvyck.xml

/netscaler/portal/templates/8cc4d5fb.xml

/netscaler/portal/templates/9HS1qhTa5cyMXYjeIdbV06LQum3nlxB2.xml

/netscaler/portal/templates/BbMZ6.xml

/netscaler/portal/templates/CHQsB.xml

/netscaler/portal/templates/E9TG5.xml

/netscaler/portal/templates/FLQBEv6FQfjjxFfjn2dSRjGHf8WjgpN6.xml

/netscaler/portal/templates/FUcrY.xml

/netscaler/portal/templates/FnMd4HqxlN0Tar9eX3sYD1L8OtPbA5gG.xml

/netscaler/portal/templates/GWwH1.xml

/netscaler/portal/templates/GbRqm.xml

/netscaler/portal/templates/GgJlo.xml

/netscaler/portal/templates/GiDNJIaYtW7EubqBCLF3rHKodsQ16wRc.xml

/netscaler/portal/templates/H8yeh.xml

/netscaler/portal/templates/H9Qwv12zTE3bUcVZMK7Wga5hBfJGxiu0.xml

/netscaler/portal/templates/HitNA.xml

/netscaler/portal/templates/JTQ5sTyzWXWdQRLHrhWukGTgvAHX8Be9.xml

/netscaler/portal/templates/MAkw4mge4.xml

/netscaler/portal/templates/NpWPYQq2DCndZfFVix74PB6owv0QrOUp.xml

/netscaler/portal/templates/O0aAJQSycUFHDsk32gflC98iTK6bRpm1.xml

/netscaler/portal/templates/O9Bon2fAzapuXry7Q0JM41LTKS8l6DmR.xml

/netscaler/portal/templates/OhjZf.xml

/netscaler/portal/templates/R8p9l.xml

/netscaler/portal/templates/RWM4aJ9GhcvSTZLxAreg0qOo5fsCuz8y.xml

/netscaler/portal/templates/TlkhDg4uyEWRHX1fxV2t9AJ3OM0iKmYz.xml

/netscaler/portal/templates/UHKl9QzvkTpJi34wqWORhGN0bDYsCPX1.xml

/netscaler/portal/templates/X3h40kvVpMxjYIKbqlwsa5eLtuNTf281.xml

/netscaler/portal/templates/YOrPCVxZizJjLauTmRyoWUf5Xg1F4G6E.xml

/netscaler/portal/templates/YP68c.xml

/netscaler/portal/templates/YjpRX.xml

/netscaler/portal/templates/a436n.xml

/netscaler/portal/templates/ad140234.xml

/netscaler/portal/templates/aenp7.xml

/netscaler/portal/templates/bf327bcc.xml

/netscaler/portal/templates/c1ktNfwQ76mDi9y2bVEY4Ze8qJajSCvs.xml

/netscaler/portal/templates/cUAwMikvxEePnrOV0bs6NRzT28lt71jq.xml

/netscaler/portal/templates/cVSMUbaDF4TeAL8C9tpmGf15PNR6sd2W.xml

/netscaler/portal/templates/cs0lxv5ppnrxebo4.xml

/netscaler/portal/templates/czqhO.xml

/netscaler/portal/templates/d12affe3.xml

/netscaler/portal/templates/dddd[%template.new({'BLOCK'='print`id`'})%].xml

/netscaler/portal/templates/dqe82VQf8.xml

/netscaler/portal/templates/eMlUc.xml

/netscaler/portal/templates/f81961c6.xml

/netscaler/portal/templates/fhLCc.xml

/netscaler/portal/templates/hK3Sn.xml

/netscaler/portal/templates/hjXNi.xml

/netscaler/portal/templates/jLBscdX0Q.xml

/netscaler/portal/templates/k42bayNsu1hxf7pZ98UwWPviVYDOAmIM.xml

/netscaler/portal/templates/niphc4KmTRS9E0XkbAo5eBQWMtsYF3zG.xml

/netscaler/portal/templates/oQZFe.xml

/netscaler/portal/templates/orfuxqzupb.xml

/netscaler/portal/templates/pswIV.xml

/netscaler/portal/templates/qTvCLFw9HnfAzFycKGJSdQ9XxOnCityF.xml

/netscaler/portal/templates/qVIgn5Mljz7as2Q6PrkDHBbmoRuhx13v.xml

/netscaler/portal/templates/qrfgO.xml

/netscaler/portal/templates/qui4o.xml

/netscaler/portal/templates/ryMG7.xml

/netscaler/portal/templates/sDZIbl7ZNsL1HVBCzowAq3oVLY2aiexj.xml

/netscaler/portal/templates/somuniquestr.xml

/netscaler/portal/templates/tcHzZ6um0MrlEVXT8dyAwBOx3kYs2go7.xml

/netscaler/portal/templates/v905U.xml

/netscaler/portal/templates/wTJIb.xml

/netscaler/portal/templates/xfWjDEZ0K4lSaRgHvecQ2987GihIYTUX.xml

/netscaler/portal/templates/yR39d.xml

/netscaler/portal/templates/yVStWwCFy9BDXBxjIGvCk3h67Gx4Zm8E.xml

/netscaler/portal/templates/yndBMhT2L.xml

Done

The results from above indicate that there are plenty of xml files that have filenames suggesting the Citrix ADC has been compromised.

Proceeding to execute the following:

shell ls /var/tmp/netscaler/portal/templates

… reveals that the /var/tmp/netscaler/portal/templates directory appears to be fine.

Executing the last command:

shell ls /var/vpn/bookmark/*.xml

> shell ls /var/vpn/bookmark/*.xml

/var/vpn/bookmark/1Fx3kynwZ.xml

/var/vpn/bookmark/OqU8uS1bW.xml

/var/vpn/bookmark/bNRrtwSjF.xml

/var/vpn/bookmark/cx4yylzvg.xml

/var/vpn/bookmark/fKchklbXP.xml

/var/vpn/bookmark/fSdeA2hEn.xml

/var/vpn/bookmark/lztbVXgWEKqmoQLWPjbM.xml

/var/vpn/bookmark/nsroot.xml

/var/vpn/bookmark/pwnpzi1337.xml

/var/vpn/bookmark/testtest.xml

/var/vpn/bookmark/z8P0sSAGK.xml

Done

>

… reveals that the /var/vpn/bookmark/ directory also displays the same type of files and suggests the ADC has been compromised.

Reviewing Apache Log Files

Executing the first 3 commands to review the Apache logs does not reveal any results:

shell cat /var/log/httpaccess.log | grep vpns | grep xml

shell cat /var/log/httpaccess.log | grep "/\.\./"

shell gzcat /var/log/httpaccess.log.*.gz | grep vpns | grep xml

However, execute the following command does:

shell gzcat /var/log/httpaccess.log.*.gz | grep "/\.\./"

The suspicious xml files are notably present in the results above.

Executing the commands to determine whether there are any scheduled tasks to maintain access after patches does not reveal any jobs that a compromised Citrix ADC would have:

shell cat /etc/crontab

shell crontab -l -u nobody

Checking for Backdoor Scripts

Executing the following two commands to look for backdoor scripts:

shell ps -aux | grep python

shell ps -aux | grep perl

… reveal the following:

> shell ps -aux | grep python

nobody 82094 0.0 0.1 60980 1852 ?? Ss 28Jan20 0:37.76 /var/python/bin/python2 -c -c (python2.7)

root 36830 0.0 0.1 9096 912 0 RL+ 1:51PM 0:00.00 grep python

> shell ps -aux | grep perl

nobody 53632 100.0 0.0 5804 272 ?? R Sun05AM 3176:31.20 /tmp/.perl

nobody 77911 0.0 0.0 5804 412 ?? I 28Jan20 0:07.52 /tmp/.perl

root 36832 0.0 0.1 9096 1024 0 S+ 1:51PM 0:00.00 grep perl

>

The presence of nobody scripts is a red flag that there are backdoor scripts currently on the NetScaler and we can see that there are 3 of them listed.

Checking for Cyrpto Mining

Executing the following command to list the current running processes:

shell top -n 10

… reveal the following:

> shell top -n 10

last pid: 36937; load averages: 2.00, 2.00, 2.00 up 123+23:58:22 13:53:29

77 processes: 3 running, 71 sleeping, 3 zombie

Mem: 27M Active, 3504K Inact, 1487M Wired, 11M Cache, 169M Buf, 2528K Free

Swap: 4198M Total, 299M Used, 3899M Free, 7% Inuse

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

1174 root 1 44 r0 1210M 1210M CPU1 1 2976.0 100.00% NSPPE-00

53632 nobody 1 119 0 5804K 272K RUN 0 53.0H 100.00% .perl

1176 root 1 44 0 83392K 5668K kqread 0 30.7H 0.00% nsnetsvc

1297 root 1 44 0 37128K 3232K kqread 0 387:11 0.00% nsrised

1434 root 1 44 0 54752K 444K nanslp 0 316:34 0.00% nsprofmon

994 root 1 44 0 76720K 1356K select 0 112:35 0.00% vmtoolsd

1199 root 1 44 0 99M 11940K kqread 0 111:55 0.00% nsaggregatord

1331 root 2 76 0 70184K 13168K ucond 0 41:09 0.00% nscopo

25 root 1 44 0 29784K 29872K kqread 0 37:05 0.00% pitboss

1314 root 1 44 0 63928K 9820K nanslp 0 30:48 0.00% nscollect

Done

>

The presence of the nobody account running a perl script that is consuming 100.00% of the WCPU suggests malicious activity currently running on the Citrix ADC.

Reviewing the Bash Logs

Executing the following 2 commands to review the bash logs:

shell cat /var/log/bash.log | grep nobody

shell gzcat /var/log/bash.*.gz | grep nobody

… does not reveal the nobody account present:

The following 2 commands display the full output of both logs allowing you to manually comb through the entries but the results from all the tests above are sufficient enough to deem the appliance as being compromised:

shell cat /var/log/httperror.log

shell gzcat /var/log/httperror.log.*.gz

Remediation

This particular environment did not have a backup pre-December 2019 for me to restore so the only viable option that was available is to redeploy the VPX appliance and restore the configuration. The latest backup I could find dates back to 2 years ago but given that there has not been any change to the Citrix ADC, I decided to download the same build, redeploy, restore backup configuration, upgrade appliance and swap out the existing one.

Prior to completing the swap it is also important to perform the following:

1. Review all of the servers that the Citrix ADC interacts with to determine whether they have been breached. These services could include domain controllers, Citrix StoreFronts, Citrix Delivery Controllers, Licensing servers and others.
2. Update all of the passwords both local to the ADC and credentials used to interact with other services such as LDAP lookups against Domain Controllers.
3. Force password changes for all users who have logged onto the ADC to access resources. As most Citrix ADCs allow Active Directory integration, it is important to force password changes for AD accounts.
4. Revoke and renew all SSL certificates on the Citrix ADC. Use the list of files on the ADC’s /nsconfig/ssl/ directory as the hackers who have breached the appliance would have been able to retrieve the files in there.
5. Ensure that the version of the Citrix ADC is not vulnerable to the CVE-2019-19781.
6. Once the above have been completed, proceed to place the Citrix ADC back on the internet and run the vulnerability scan against it.

Restoring Configuration from Backup

As indicated above, the backup I had to work with was a few versions back from the NS12.1 51.19.nc that the appliance was currently running:

Citrix’s official Backup and Restore documentation (https://docs.citrix.com/en-us/netscaler/12/system/basic-operations/backup-restore-netscaler-appliance.html) indicates we can use the same or newer build but just to avoid any unintended issues, I downloaded the same build and redeployed the appliance as the running version would need to be upgraded anyways. The first step for the restore is to get the backup file uploaded and since a restore can only be performed via the GUI, I will use it to upload the configuration backup.

Begin by navigating to System > Backup and Restore then click on the Backup button:

Select the Add button:

Click on the down arrow beside Choose File and select Local as the source then select the backup TGZ file:

**Note that it is important to choose the Local option because the Appliance option would allow you to upload but it will not be displayed as a backup in the options to restore.

With the backup uploaded, proceed to restore it from the TGZ package:

Note that there is no need to have backup the appliance since it’s a new deployment so select the Skip Backup checkbox:

The restore should be fairly quick and will display a Restore Successful at the bottom right hand corner of the window:

The restored configuration will not be active until you restart the appliance and it is important to not select Save configuration if you restart it from the GUI or else the empty configuration will overwrite what you have just restored.

Also note that the IP address configuration will match the original appliance so if you have left the other one online for forensics but prevented it from accessing the internet then you should either change its IP address to avoid conflict or move it to another network.

If you’re staging the new appliance and have not given it network connectivity then the following are useful commands to verify the restored configuration:

• show ip – list the NSIP, SNIP, SIP, MIP, VIP IP addresses
• show lb vserver – displays the Load Balancing Virtual Servers details
• show lb vserver -summary -fullvalues – displays the list of Load Balancing Virtual Servers without truncating names (use | grep to add specific values to list such as UP or DOWN)
• show ssl certKey – to list all certificates on the appliance
• show ssl certLink – to list the links between Root CA and Subordinate CA certificates

It’s important to note that the previously installed Client certificates will be present but you should deem these as being compromised so proceed to revoke, reissue and reinstall those certificates.

Attempting to rebalance VMware Horizon View linked-clones desktop pool datastore fails with: "Refit operation rebalance failed"

Problem

You attempt to migrate a linked-clone pool’s storage from one datastore to another by using the rebalance feature as outlined in the following KB:

Migrating linked clone pools to a different or new datastore (1028754)
https://kb.vmware.com/s/article/1028754

… but notice that the operation attempts the migration on a few desktops but fails with the error: Refit operation rebalance failed in the Events log of the linked-clones desktop pool:

Clicking on the ellipsis icon for the error for more information does not reveal additional information:

Navigating outside of the Events log of the linked-clones desktop pool then into the Inventory view and clicking on the ellipsis icon for the desktop in error displays the following message:

Apr 5, 2019 8:34:03 PM ADT: View Composer Invalid Parent VM Fault: View Composer Invalid Parent VM Fault: Selected snapshot on parent VM is not found on VC server

Pairing state:

Configured by:

Attempted theft by:

Solution

This error is usually caused by situations where the master image for the linked-clones pool no longer have the snapshots that the desktops being moved are associated with.  The rebalance operation requires access to the snapshots in order to re-clone the replicas (snapshots) to the new datastore so if they no longer exist then this error would be thrown.  In the case of the environment, the pool of 200 desktops had a mix of 5 different snapshots where only 1 of them was still available on the master image.  To view the linked-clones desktops and the associated snapshot that are being used, navigate to Inventory > Machines (View Composer Details) and review the Image tab:

If the snapshots have already been deleted then the way to remediate the error is to recompose all the snapshots with an existing snapshot on the master image or create a new one and recompose with it.  The rebalance operation should complete successfully once all the linked-clone pools are using a snapshot that exists.

Deploying Skype for Business Server 2019 Archiving and Monitoring Services

Deploying Skype for Business Server 2019 archiving and monitoring services are fairly much the same as the previous version but I thought it would be a good idea to write this updated post to demonstrate the process.  Before I begin, note that the official planning documentation Monitoring can be found here:

Deploy archiving for Skype for Business Server
https://docs.microsoft.com/en-us/skypeforbusiness/deploy/deploy-archiving/deploy-archiving

Deploy monitoring in Skype for Business Server
https://docs.microsoft.com/en-us/skypeforbusiness/deploy/deploy-monitoring/deploy-monitoring

Step #1 – Define Archiving and Monitoring services on Front End Server / Pool Properties

Begin by editing the properties of the front-end pool, navigate to the General properties and scroll down to the Associations section:

Enable the Archiving and Monitoring (CDR and QoE metrics) options:

Enter the FQDN of the SQL server that will be hosting the two databases when presented with the Define New SQL Server Store menu:

Select the same or create a new SQL instance for the monitoring service then click OK:

The archiving SQL Server store and Monitoring SQL Server store should now have the new SQL server instance defined:

Publish the topology:

The Publish Topology wizard will present you with the option to either automatically let the wizard determine where to store the database or manually changing the path by going into the advanced options:

Selecting advanced will present the following menu:

What I don’t like about this is that the database doesn’t get stored in the paths defined but rather in sub folders such as D:\Database\ArchivingStore\(default)\DbPath.  You can, obviously, change this afterwards or at least have them on the correct drives.

Step #2 (Optional) – Move SQL database and log files to appropriate location

If you are not satisfied with the path in which the database and the log files are stored, you can use the following SQL queries to change the path after taking the database offline:

ALTER DATABASE LcsCDR  

    MODIFY FILE ( NAME = LcsCDR_data,  

                  FILENAME = 'D:\Database\LcsCDR.mdf'); 

GO

ALTER DATABASE LcsCDR  

    MODIFY FILE ( NAME = LcsCDR_log,  

                  FILENAME = 'D:\Log\LcsCDR.ldf'); 

GO

ALTER DATABASE LcsLog  

    MODIFY FILE ( NAME = LcsLog_data,  

                  FILENAME = 'D:\Database\LcsLog.mdf'); 

GO

ALTER DATABASE LcsLog 

    MODIFY FILE ( NAME = LcsLog_log,  

                  FILENAME = 'D:\Log\LcsLog.ldf'); 

ALTER DATABASE QoEMetrics  

    MODIFY FILE ( NAME = QoEMetrics_data,  

                  FILENAME = 'D:\Database\QoEMetrics.mdf'); 

GO

ALTER DATABASE QoEMetrics 

    MODIFY FILE ( NAME = QoEMetrics_log,  

                  FILENAME = 'D:\Log\QoEMetrics.ldf'); 

GO

Step #3 – Deploy Monitoring Reports on SSRS

With the databases created, proceed by launching the Deployment Wizard and click on Deploy Monitoring Report:

Select the appropriate SQL instance and define the SQL Server Reporting Services (SSRS) instance:

**Note that as the wizard indicates, this will overwrite existing reports so be cautious of any SSRS reports that may already exist on the server.

Enter an account that will be used to access the Monitoring database:

I’ve been asked many times in the past about what credentials should be entered and the short answer is to use a service account because this account will be granted required logon and database permissions to the database in order for it to access the database.  The documentation about this can be found here:

Install Monitoring Reports in Skype for Business Server
https://docs.microsoft.com/en-us/skypeforbusiness/deploy/deploy-monitoring/install-monitoring-reports

On the Specify Credentials page, in the User name box, type the domain name and user name of the account to be used when accessing the Monitoring Reports (for example, litwareinc\kenmyer). If you do not use this format (domain\user name) an error will occur.

Type the user account password in the Password box, and then click Next. Note that no special rights are required for this account. The account will automatically be granted the required logon and database permissions when setup completes.

I usually prefer to create a service account for this:

Define a group that will have read-only access to SQL Server Reporting Services (SSRS):

**Note that the default is RTCUniversalReadOnlyAdmins

The wizard will complete the deployment with the information provided:

Once completed, you should see the service account granted ReportsReadOnlyRole to the databases:

Step #4 – Test Monitoring services reports

The reports can now be accessed via the following URL:

http://<SSRS_Server>/reportserver

Step #6 – Configure Monitoring and Archiving Reports

It is generally not advisable to just leave the configuration for the monitoring or archiving reports as the default (you should at least review the default settings to ensure it meets the requirements of the organization) so proceed to launch the Skype for Business Server 2019 Control Panel and navigate to Monitoring and Archiving:

Go through the menus and edit the global properties or create a new one for the organization: