I am having issue with citrix web studio, when I launch the message come up with site requires upgrade.
so I am trying to click automatic site upgrade and its is failing with
ith Error Id: XDSM:04CB7638
Exception:
Error Source : Citrix Studio
StackTrace: Citrix.Console.Common.CitrixAggregateException One or more parallel operations failed
at Citrix.Console.Common.CitrixParallel.InternalForEach[TIn](IEnumerabl1 items, Action1 operation, Int32 maxSimultaneous)
at Citrix.Orchestration.Base.PowerShellSdk.UpgradeService.UpgradeTasks.DataMigration.FixBlankDesktopNameTask.GetUpgradeRequirement(IProgressReporter progressReporter, UpgradeStatusModel upgradeStatusModel)
at Citrix.Orchestration.Base.PowerShellSdk.UpgradeService.UpgradeTasks.UpgradeTaskBase.AssessUpgradeRequirement(IProgressReporter progressReporter, UpgradeStatusModel upgradeStatusModel)
at Citrix.Orchestration.Base.PowerShellSdk.UpgradeService.UpgradeTasks.DataMigration.DataMigrationTasks.GetUpgradeRequirement(IProgressReporter progressReporter, UpgradeStatusModel upgradeStatusModel)
at Citrix.Orchestration.Base.PowerShellSdk.UpgradeService.UpgradeTasks.UpgradeTaskBase.AssessUpgradeRequirement(IProgressReporter progressReporter, UpgradeStatusModel upgradeStatusModel)
at Citrix.Orchestration.Base.PowerShellSdk.UpgradeService.UpgradeTasks.UpgradeTaskBase.RunUpgrade(IProgressReporter progressReporter, ITaskLogger taskLogger)
at Citrix.Orchestration.Base.PowerShellSdk.UpgradeService.UpgradeTasks.Upgrade.RunUpgradeTask(IProgressReporter progressReporter, ITaskLogger taskLogger)
at Citrix.Orchestration.Base.PowerShellSdk.UpgradeService.UpgradeTasks.UpgradeTaskBase.RunUpgrade(IProgressReporter progressReporter, ITaskLogger taskLogger)
at Citrix.Console.DeliveryCenter.UI.Mmc.UpgradeResultPaneViewModel.UpgradeTask(IProgressReporter progressReporter, UserCredentials adminDatabaseCredentials, UserCredentials serviceDatabaseCredentials)
at Citrix.Console.Common.OperationTimer.TimeBlock(Action operation)
at Citrix.Console.CommonControls.ProgressDisplay.GenericProgressOperationWithFeedBack.PerformOperationInternal()
at Citrix.Console.CommonControls.ProgressDisplay.ProgressWindowOperation.PerformOperation()
at Citrix.Console.CommonControls.ProgressDisplay.ProgressWindowViewModel.PerformAction(Action operationComplete)
Inner Exception:
DesktopStudio_ErrorId : UnknownError
ErrorCategory : NotSpecified
DesktopStudio_PowerShellHistory : SimplePowerShellScript
please advice how to fix this issue
]]>We recently upgraded one of our vSphere environments to VCF 9.1. As part of the migration, we broke the existing Enhanced Linked Mode configuration and moved authentication to VCF SSO using the Identity Broker.
After that change, we ran into an issue with the service account used by Horizon to integrate with vCenter. The account was an AD/domain service account and it stopped authenticating correctly after the SSO transition.
As a temporary workaround, we created a local vSphere service account and assigned the required Horizon/vCenter permissions, as well as the necessary VCF roles. That restored the integration.
Have you come across this scenario with Horizon and VCF 9.x Identity Broker?
I’m particularly interested in what you consider the recommended approach for non-interactive service accounts in this architecture. Should an AD-based Horizon service account continue to work through VCF SSO/Identity Broker, or is a local vSphere account currently the safer/recommended option?
We’d prefer not to keep the local account as the long-term solution if there is a supported way to maintain the domain service account.
]]>Remove vTPM from golden master image if you enabled and second disable bitlocker service and decrypt the C-Drive if encryption is enabled. During pool creation, you can choose vTPM option, not on master image level. Otherwise that would trigger customization timed out error.
]]>Add this reg key on the golden image and test:
reg add “HKLM\System\CurrentControlSet\Control\BitLocker” /v “PreventDeviceEncryption” /t REG_DWORD /d “1” /f
After every sysprep, windows automatically enabling BitLocker on the drive and had to disable it.
]]>I have a scenario with a Citrix VPX. Most of the time, I see users from the Internet attempting to log in to the Citrix VPX Management IP.
I have already enforced a policy on the network firewall to restrict access to the Management IP, but it has not resolved the issue. I am still seeing unauthorized login attempts from external users.
Could you please advise on the best way to secure the Management IP and prevent these intrusion attempts?
carl pls reply to this query i dont have any one published clear document on this
]]>The UAG RADIUS connection is pointed at an Imprivata appliance. MFA works fine through this connection using the ImprivataID application installed on a users phone.
My org leadership now wants to enable MFA on all internal connections to the VDI desktop environment with a 12 hour ‘grace’ period.
If I configure RADIUS on the internal connection servers I can get the MFA prompt but it’s at every login or unlock.
Users are currently doing Tap and Go via Imprivata and a 10ZiG integration. The 10ZiG devices we have contain an embedded ProveID agent but they’re not not certified for ImprivataID and thus doesn’t know what to do with that logon method declared as a second factor authentication.
Are you able to point me in a good direction for how might I implement MFA on the internal connections with a grace period?
Many thanks.
]]>Hey all, hoping someone has run into this before opening a can of worms with support.
Setup:
Fresh, first-time Session Recording install (no prior deployment, not an upgrade)
Single Session Recording server, Windows Server 2022 Datacenter
SQL Server 2022 (Enterprise), on a separate/remote server from the SR server
Installing account has sysadmin on the SQL instance
What happens:
Tried installing Session Recording Administration via both the standalone MSI and the full CVAD metainstaller, across three different product versions:
25.7 (2507 Current Release)
24.2 LTSR CU4
25.7 LTSR CU1
All four attempts fail in the exact same custom action (SsRecDatabase.dll.install), with two distinct errors depending on which authentication method I use for the DB connection:
1. Windows Integrated Authentication (default, no explicit DB credentials):
Error 1001. Database ‘CitrixSessionRecording’ already in use.
MSI (s): Leaked MSIHANDLE (150) of type 790531
DEBUG: Error 2769: Custom Action SsRecDatabase.dll.install did not close 1 MSIHANDLEs.
CustomAction SsRecDatabase.dll.install returned actual error code 1603
The DB and schema actually get created successfully (confirmed on the SQL side – table populated, no errors server-side), but the custom action then fails its own internal “is this DB in use” check – because it apparently never closed its own connection. Time-to-failure varies a lot between attempts (4 sec to 112 sec), which smells like a race condition, possibly only surfacing because SQL is on a separate host (network teardown latency) rather than co-located.
2. SQL Authentication (entering a SQL login in the credential prompt or metainstaller DB screen):
The installer silently sets an internal AZURESQLSERVICESUPPORT=1 flag (even though this is on-prem SQL Server, not Azure SQL at all), and fails with a completely different, genuine error:
Error 1001. Invalid column name ‘id’.
CustomAction SsRecDatabase.dll.install returned actual error code 1603
Looks like that code path queries a column that doesn’t exist in the schema being used.
What I’ve ruled out:
Network/firewall (port 1433 reachable, clean TCP test)
SQL permissions (sysadmin confirmed)
Leftover DB artifacts (dropped/recreated DBs before every attempt, verified zero open sessions/locks via sys.dm_exec_sessions each time)
SQL Server “Force Encryption” (confirmed off)
TLS/.NET strong crypto registry settings (added them, rebooted, no change)
AV/EDR interference (none installed on the box)
System/user culture (tried both a Turkish culture and en-US, identical “Invalid column name ‘id'” result in the SQL-auth path either way)
SQL Server error log shows nothing during the failure window – no rejected logins, no errors
Given it reproduces identically across 3 separate product versions/builds and both possible auth paths, this doesn’t look environment-specific to me anymore – looks like a genuine defect in the shared DB setup code that only shows up when SQL Server isn’t co-located with the Session Recording server.
Has anyone seen this, or found a workaround (e.g. installing with DB temporarily local, then pointing to the real instance after)? Case is open with Citrix support, just curious if this is a known one in the wild.
]]>