Error on Studio: “A working instance for the Configuration Logging Service could not be found”

1. Restart the Citrix services with the following PowerShell commands and then close and reopen Studio:

  • Get-Service Citrix* | Stop-Service -Force
  • Get-Service Citrix* | Start-Service

Note: Studio is not going to show the same error message anymore, and it should prompt for a Mandatory upgrade again. Do not proceed with the upgrade yet, and make sure you have a good backup of the database before continuing with the following steps.

2. Re-register the Log and Monitor services connection strings with the following PowerShell commands:

Set-MonitorDBConnection -DataStore Monitor -DBConnection $nullSet-MonitorDBConnection -DBConnection $nullSet-LogDBConnection -DataStore Logging -DBConnection $nullSet-LogDBConnection -DBConnection $null
$cs="Server=$ServerName;Initial Catalog=$SiteDBName;Integrated Security=True"$csLogging= "Server=$ServerName;Initial Catalog=$LogDBName;Integrated Security=True"$csMonitoring = "Server=$ServerName;Initial Catalog=$MonitorDBName;Integrated Security=True"
Set-LogDBConnection -DBConnection $csSet-LogDBConnection -DataStore Logging -DBConnection $csLoggingSet-MonitorDBConnection -DBConnection $csSet-MonitorDBConnection -DataStore Monitor -DBConnection $csMonitoring

3. Proceed with the Mandatory upgrade on Studio by clicking the “Start the automatic Site upgrade” button. If prompted, enter the credentials used by the controllers to connect to the database.

4. Wait for the upgrade to finish, and then Studio should start to work properly.

Related:

  • No Related Posts

Unable to Configure Citrix App Layering ELM PVS Connector

The App Layering Agent (PVS Agent) on the PVS server is registered with the App Layering ELM virtual appliance, and the PVS Server enumerates on the App Layering PVS connector screen. However, clicking “check credentials” an error is displayed stating that the ELM cannot use the credentials on the PVS server since it does not have the rights to execute remote PowerShell commands.

You may also see “Cannot communicate with PVS on server ‘ServerName’. Please ensure that the PVS Powershell Snapin has been registered”.

Related:

  • No Related Posts

“Access is denied” error while login to a Windows Server 2008 R2 SP1 with Citrix VDA7.15 CU installed

To fix this Access is denied error, add following registry and restart the server.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal Server

Name: IgnoreRegUserConfigErrors

Type: REG_DWORD

Value: 1

HKLMSystemCurrentControlSetControlLsaKerberosParameters

Name: MaxTokenSize

Type: REG_DWORD

Value: 48000 (Decimal)

Related:

Devices created with XDSW to Citrix Cloud Result in Devices being left in initial zone 

Short Term Mitigation:

Manually move the devices from the initial zone after creation with the Powershell SDK until upgrade to 1912+ PVS is completed.

Resolution:

Upgrade pvs console and server to a version 1909+

Related:

StoreFront – Citrix Subscriptions Store service not starting up on one storefront server in server group

Export the subscription data using PS on the working server.

https://docs.citrix.com/en-us/storefront/current-release/configure-manage-stores/manage-subscription-data.html

Then remove contents of folder C:WindowsServiceProfilesNetworkServiceAppDataRoamingCitrixSubscriptionsStore on both Storefront Servers,

The follow the steps in the section “Restoring Data on a StoreFront Server Group”

Stop the Subscriptions Store service on working Storefront server..

Restore the data on non-working server using the Restore-STFStoreSubscriptions cmdlet.

Restart the Subscriptions Store service on servers StoreFront2.

It will then receive a copy of the data from StoreFront1.

Related:

Microsoft Exchange: 355000 Servers Lack Critical Patch

Governance & Risk Management , IT Risk Management , Patch Management

Fix Released in February Only Installed on 18 Percent of Servers, Rapid7 WarnsMathew J. Schwartz (euroinfosec) • April 8, 2020

Microsoft Exchange: 355,000 Servers Lack Critical Patch
Rapid7: Any attempts to exploit CVE-2020-0688 will leave artifacts in the Windows and IIS logs, including the name of the legitimate user account that was used.

Patch or perish alert: Less than than 20 percent of all Microsoft Exchange servers have received a fix for a serious flaw Microsoft first disclosed nearly two months ago, security firm Rapid7 warns.

See Also:Live Webinar | Can Medium-Sized Companies Automate Access to Critical Multi-Cloud IT Environments?

“As of March 24, there were over 350,000 Exchange servers exposing a version of the software that has this vulnerability,” writes Tom Sellers, a senior manager at Boston-based Rapid7 Labs, in a blog post.

The vulnerability could allow a remote attacker “to turn any stolen Exchange user account into a complete system compromise,” he says. “In many implementations, this could be used to completely compromise the entire Exchange environment – including all email – and potentially all of Active Directory” (see: Why Hackers Abuse Active Directory).

Microsoft addressed the remote-code-execution vulnerability – designated CVE-2020-0688 – via security updates it released on Feb. 11 for all supported versions of Microsoft Exchange. At least at that point, the flaw didn’t appear to have been targeted in the wild, the company said. The flaw was reported to Microsoft by an anonymous researcher via Trend Micro’s Zero Day Initiative.

“A remote-code-execution vulnerability exists in Microsoft Exchange Server when the server fails to properly create unique keys at install time,” Microsoft said in its security alert. “Knowledge of the validation key allows an authenticated user with a mailbox to pass arbitrary objects to be deserialized by the web application, which runs as SYSTEM. The security update addresses the vulnerability by correcting how Microsoft Exchange creates the keys during install.”

Security Updates Include Patch

To fix the flaw, Microsoft pushed security updates for four base versions of Exchange:

  • Exchange Server 2010 service pack 3 update rollup 30;
  • Exchange Server 2013 cumulative update 23;
  • Exchange Server 2016 cumulative update 14;
  • Exchange Server 2016 cumulative update 15;
  • Exchange Server 2019 cumulative update 3;
  • Exchange Server 2019 cumulative update 4.

But the vast majority of these servers remain unpatched, according to a survey conducted by Project Sonar, Rapid7’s in-house internet scanning project (see: Is COVID-19 Driving a Surge in Unsafe Remote Connectivity?).

“On March 24, we used Project Sonar to survey the internet for publicly facing Exchange Outlook Web App – OWA – services,” Sellers says. “What we found was that at least 357,629 (82.5 percent) of the 433,464 Exchange servers we observed were known to be vulnerable.”

Subsequently, Sellers added a caveat that 35,000 fewer servers might be vulnerable, owing to Microsoft’s fix for Exchange 2010 not updating the visible build information, meaning that scans alone could not tell if an Exchange 2010 system had been updated. Instead, organizations will need to manually verify that every such system has the update. Sellers says they should do the same for all Exchange 2013 and newer systems, noting that the build number alone should indicate if the relevant update is in place.

Check for Compromise

Rapid7 also recommends all organizations that use Exchange search for any signs that they have been compromised via this flaw.

“The exploit code that we tested with left log artifacts in the Windows Event Log and the IIS [Internet Information Services] logs on both patched and unpatched servers,” Sellers says, noting that the log error message will also name the compromised user account.

“You will see the username of the compromised account name at the end of the log entry,” according to Rapid7’s Tom Sellers

Because the attack requires a valid Exchange user account to succeed, “any user accounts seen in these exploitation attempts should be considered compromised,” Sellers says.

But Wait, There’s More

Unfortunately, the Project Sonar scans revealed more widespread problems than a lack of CVE-2020-0688 patching. Notably, Rapid7 researchers found 31,000 Exchange 2010 servers online that had received no updates since 2012, as well as 800 Exchange 2010 servers that have never been updated. It also saw 10,371 Exchange 2007 servers.

“In addition to the high numbers of servers that are missing multiple updates, there is a concerning number of Exchange 2007 and 2010 servers,” Sellers says, although he notes that Exchange 2007 is not vulnerable to CVE-2020-0688. Even so, the unsupported operating system long ago stopped receiving security updates, and now has a raft of critical flaws that attackers could exploit. “Exchange 2007 transitioned to ‘end of support’ status nearly three years ago, on April 11, 2017,” he says. “No security updates, bug fixes, time zone updates, etc., are provided after that date.”

Exchange 2010 was scheduled to reach end of support on Jan. 14, although that’s now been postponed until Oct. 13, 2020. “There are over 166,000 of these servers connected to the internet,” Sellers says. “That’s a staggering number of enterprise-class mail systems that will be unsupported in a few months.”

Related:

Storefront 3.12 CU5 Error: Propagation failed on one or more Servers

PROBLEM:

When administrator launches Storefront Management Console and attempts to perform “Propagate Changes” on Servers , the process fails with the following error:

Error: Propagation failed on one or more Servers


Event logs on Primary Server shows the following event:

Event ID 31

An error has occurred during the all server configuration update process.

Citrix.DeliveryServices.ConfigurationReplication.Exceptions.ServerUpdateConfigurationException, Citrix.DeliveryServices.ConfigurationReplication, Version=3.12.0.0, Culture=neutral, PublicKeyToken=e8b77d454fa2a856

Could not find an X509Certificate2 certificate with the specified thumbprint.

RemoteEndpoint: net.tcp://fantailwillow02/Citrix/ConfigurationReplication

On the Secondary Server the following events are seen:

Event ID 19

Failed to get the end status of the sever configuration update.

System.ServiceModel.FaultException, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

Could not find an X509Certificate2 certificate with the specified thumbprint.

at Citrix.DeliveryServices.ConfigurationReplication.WCF.ConfigurationReplication.EndUpdateConfiguration(IAsyncResult asyncResult)

AND Event ID 12

Failure to notify of configuration update.

Citrix.DeliveryServices.ConfigurationReplication.Exceptions.ClusterMemberCertificateNotFound, Citrix.DeliveryServices.ConfigurationReplication, Version=3.12.0.0, Culture=neutral, PublicKeyToken=e8b77d454fa2a856

Could not find an X509Certificate2 certificate with the specified thumbprint.

CertificateThumbprint: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Related:

  • No Related Posts