Showing posts with label XenDesktop. Show all posts
Showing posts with label XenDesktop. Show all posts

Friday, 1 March 2019

Citrix Provisioning Servers gone offline

Under normal operation, PVS servers show up green in Provisioning Services Console.
Mine went orange and became unavailable, tried the following:
Tried making a change to the farm config like add a new collection. This returned a database error. 
On clicking more details, it clarified: the transaction logs had become full.
The details of the database can be found by right-clicking the farm and select properties. On the last tab the details of the dB and instance are listed.
This issue was resolved once the volume on which the database stores transaction logs on was cleared up, by running backups in our case, as the Edgesight, PVS and XenDesktop dB's all stored logs on the one volume.

Monday, 24 October 2016

Move Existing XenDesktop 5.6 Database to New SQL Server

In the event of a db failure and mirror not kicking in - I still need to figure out why...


ensure all users are logged off, this may be redundant as they may not be able to get in.


on each DDC run the following PowerShell:


asnp Citrix*

Set-ConfigDBConnection -DBConnection $null
Set-AcctDBConnection -DBConnection $null
Set-HypDBConnection -DBConnection $null
Set-ProvDBConnection -DBConnection $null
Set-PvsVmDBConnection -DBConnection $null
Set-BrokerDBConnection -DBConnection $null


Each of these lines if successful will return a DBUnconfigured in PowerShell.



DB connections have to be set to $null before they can be pointed elsewhere. This is a built in thing.




These steps above and below have to be done in the order presented otherwise some of the connections won't be nullified.






Next we point to the new SQL instance and set the new mirror too along with some other essential setting:





Set-ConfigDBConnection -DBConnection "Data Source=DBServerName\DBInstance; Failover Partner=MirrorDBServerName\MirrorDBInstance; Initial Catalog=XENDESKTOP; Integrated Security=True; Network=dbmssocn"

Set-AcctDBConnection -DBConnection "Data Source=DBServerName\DBInstance; Failover Partner=MirrorDBServerName\MirrorDBInstance; Initial Catalog=XENDESKTOP; Integrated Security=True; Network=dbmssocn"

Set-HypDBConnection -DBConnection "Data Source=DBServerName\DBInstance; Failover Partner=MirrorDBServerName\MirrorDBInstance; Initial Catalog=XENDESKTOP; Integrated Security=True; Network=dbmssocn"

Set-ProvDBConnection -DBConnection "Data Source=DBServerName\DBInstance; Failover Partner=MirrorDBServerName\MirrorDBInstance; Initial Catalog=XENDESKTOP; Integrated Security=True; Network=dbmssocn"

Set-PvsVmDBConnection -DBConnection "Data Source=DBServerName\DBInstance; Failover Partner=MirrorDBServerName\MirrorDBInstance; Initial Catalog=XENDESKTOP; Integrated Security=True; Network=dbmssocn"

Set-BrokerDBConnection -DBConnection "Data Source=DBServerName\DBInstance; Failover Partner=MirrorDBServerName\MirrorDBInstance; Initial Catalog=XENDESKTOP; Integrated Security=True; Network=dbmssocn"

Each of these lines if successful will return an OK in PowerShell.

Once these steps have been carried out across all of your controllers, your Studio Console will fire back up without issue, and users should be able to login.






Next to deal with is PVS.




We had to try to rerun the PVS config wizard but were being prompted for SQL credentials and couldn't continue. Fortunately our DBA managed to repair and restore the original PVS DB.