VMware View 4 - newspapers PCoIP

Similar Questions

• VMWare View 4.6 PCoIP tunneling problem. UDP is not get tunnel

  
  Hello

  I have the black screen "classic" - question.
  So, when I try to connect to a virtual desktop, I am well auhtenticated, I can select a pool of offices, but once the bureau is launching,
  I just get a black screen and afterawhile it times out.

  I read the manuals, the document http://communities.VMware.com/docs/doc-14974 , written by Mark benson; Watched the video; Checked and re-checked the 3 magic steps;
  Blog reading Sláger, Paul http://paulslager.com/?p=1300 and still I'm stuck. I read the (some the) logs from the login view, view Security Server, View Client and Agent of the view server.
  None of the newspapers I read gave me all significant errors that would have solved this for me. Admitted, 'full' newspapers - trace State, there's a lot that wasn't exactly clear to me.

  I have simplified our mitigation debugging environment to be as follows:

  See connection to the server,
  running on Windows Server 2008 R2 (Datacenter) 64-bit VMware View Server connection 4.6.0 - 366101,.
  Checkboxes for both "Tunnel secure HTTPS: connection to Tunnel secure usage on the desktop" and "PCoIP Secure Gateway: use PCoIP PCoIP Gateway Secure connections to desktop" have been checked.

  View secure server,
  running on Windows Server 2008 R2 (Datacenter) 64-bit VMware View Server Security 4.6.0 - 366101,.
  has been paired with the login server and the two aswell "HTTPS Secure Tunnel: external URL" as "PCoIP Secure Gateway: PCoIP external URL" has been set to a virtual IP address in the firewall external dmz with a dst - nat on the real IP address of the Security Server.

  The reviews are pointing to the virtual IP address of the Server Secure View.

  Since it is not a production environment, I installed a bunch of Wireshark to see traffic;
  I ran traffic snooping on the view connection server, see Security Server, View Client and the virtual desktop connected
  at the same time and have verified that traffic TCP PCoIP on get 4172 port of talked about between my security server host <>client - and the
  securityserver <>- virtual desktop just fine. TCP traffic seems to be in the tunnel. But what bothers me is the wireshark on the virtual office reveals that the virtual office is trying
  to talk subject port 4172 - UDP back directly to my reviews host IP traffic. Because this is not allowed by the firewall, the virtual office propably does not work...

  But all scenarios describe only the Security server could handle all pcoip-traffic with the agent of the view (as shown in the documentation of the Architecture in Figure 5-6), so that no direct connection between the Client of the view and the view Agent is necessary... I can't work. But it is possible, right?

  Any ideas what I could do wrong?

  Help really appreciated.

  It works in the way that you described in your original post. There is no obligation for the virtual office send UDP responses to the client. They will be sent on the Security Server, which will forward them to turn to the customer.

  Something must be configured incorrectly.

  Check very carefully the UDP traffic in your wireshark traces. The client, you should see 4172 TCP for the VIP of your SS. You should then see 4172-UDP to the same VIP. You should see the UDP of SS response to the customer data. The destination for this data answer UDP port must be the source port used for the UDP request. The source for the response data port must be 4172.

  Then check your wireshark SS track. You should see the same customer traffic and you should see a similar PCoIP conversation between the SS and the virtual office. From the virtual desktop, the SS looks like a customer. PCoIP UDP must be sent to the SS, when it is properly configured.

  Client - TCP 4172-> SS - TCP 4172-> Virtual Office

  Customer - UDP 4172-> SS - UDP 4172-> Virtual Office

  Customer<-UDP 4172--="" ss=""><-UDP 4172--="" virtual="" desktop="" (the="" 4172="" here="" is="" src="" port,="" the="" dst="" udp="" port="" will="" be="" the="" source="" port="" of="" the="" udp="" request="" packets="" above)="" 4172--="" virtual="" desktop="" (the="" 4172="" here="" is="" src="" port,="" the="" dst="" udp="" port="" will="" be="" the="" source="" port="" of="" the="" udp="" request="" packets="">

  If you have verified that you can connect to the same virtual desktop with PCoIP then this problem will not be something to do with the virtual office or agent of view etc.

  Check your display settings, network, firewall and NAT.

  Select this option.

• VMware View - RDP works, PCoIP mit error

  HI Leute

  ICH habe bei meiner VMware View Architektur das problem, dass ich beim Verbinden uber den View Client nur das Protokoll RDP use kann. DAS will work wunderbar. As soon as ich aber das PCoIP Protokoll auswahle, kommt also Fehlermeldung beim Verbinden:

  Dieser Office steht zurzeit nicht available. Try later Rubis, eine connection Sie mit diesem herzustellen office, oder wenden Sie sich an your Systemadministrator.

  ICH use VMware View 4.6, mit zugehorigem vCenter Server und connection to the server. Alles ist auf dem could Stand. Am is nicht mit einem Security Server. Lafut're too im trainee alles Moment.

  Die virtuellen Maschinen, die ich mich verbinden laufen auf mit Win 7 x 64

  Hat eine idea, wo yesterday someone das problem konnte liegen? Habe ich vergessen oder please konfiguriert something?

  ICH würde mich freuen, wenn einen Losungsansatz had someone.

  Grüße

  Bopa

  OK, so I ran it through a translator and got the below.

  People in the back, I have the problem with my VMware View architecture that I can use the minutes RDP with the connection by the Client to view only. Will work wonderfully. As soon as I select the PCoIP minutes however, the following error message is delivered with connection: this office is not available at the present time. Try again later connection with this desktop computer or contact your system administrator. I use VMware View 4.6 with partner vCenter server and connecting to the server. Everything is on the latest terms. I'm not however with a security server. It lafut so for now everything in-house. Virtual machines, on which I connect run me with Win 7 x 64 does anyone have an idea, the problem could lie where here? A I forgot something or configured incorrectly? I would be happy, if someone had a solution. Greetings

  So, it sounds like RDP works but you are having problems with PCOIP and everything is internal.    Have you checked that PCOIP is not blocked by any firewall?  It uses the port 4172 so make sure that you unlock that.    Also is this a problem with this particular machine or all of your machines?

• Test environment for VMware View 7 - PCoIP Protocol does not work properly

  We test VMware View 7 with as many Thin Clients and customers zero (Teradici)

  When we try to connect via RDP Protocol, it works fine. When we try to connect via the PCoIP Protocol, desktop display seems to blink (about 2 times per second) and display resolution is not acceptable. So, there is a problem with the Protocol (broker or Office VM)

  There are no firewall in the middle.

  Desktop virtual has a clean install.

  So... anyone have the same number? or similar?

  How much video Ram?

  You can increase the video Ram.

• VMware VIew 6 (PCOIP): Windows Client and web browser connects, Android and Ubuntu - don't

  Hello colleagues!

  VMware Horizon Client 3.4.0 build-2769709

  VMware View 6.1.1 construction-2769403

  VMware vSphere 6.0.0 2776511

  That's what's wrong: used SecurityServer and connecting to the server. External connection - via a router. When it is connected to a vmware PCOIP Protocol (Internet) outside of the view with a Windows client and a web browser, it works fine. But when connecting from Android or Linux (Ubuntu 14) load the desktop does not occur. Android immediately displays the message 'connection to server lost', Ubuntu delivers all messages - I'll be back on the screen to select a pool table.

  Which connection via MS RDP connection protocol is correctly to all customers.

  In the settings ConnectionServer in PCOIP Security Gateway set up the external address of the router.

  Redirect them router ports:

  -TCP 80,443,8443,4172,32111

  -UDP 4172,32111

  Any ideas?

  In security settings server in 'URL of PCOIP' was FQDN, but it must be the IP address.

• VMWARE HORIZION VIEW 6.0: it does not serve any which RDS (using PCoIP) session to my zero Teradici Clients but it works with Horizon of VMware View client 3.0.0 from my computer

  Hi all

  I'm testing view Horizon 6.0 Service sessions (Windows 2008 R2) RDS through PCoIP. I think that my setup is just because I can connect via Horizion View Client (installed in my laptop or my Android smartphone). But when I try to connect from a Client Tera zero, 1 or 2 (with the latest firmware), at the same time I did logon, I still have this error:

  "View server connection has no return of available virtual desktops."

  Could someone tell what can be wrong?

  Concerning

  As a result of this discussion "Re: RDS support is included in Vmware View (broker)?" I saw that I must spend my customers zero to 4.5.1 firmware. Once I did, Tera 2 Zero Clients work very well but do not have customers zero 1 Tera.

  I expect response from Teradici.

  Concerning

• VMware View Agent 5.2.0 PCoIP over WAN fails

  Recently, I did an upgrade on VMware View VMware view horizon 5.2 4.6 square.

  After the upgrade the 4.6.0 view agent in virtual machines of my parents to view agent 5.2.0 and rebuild the office pools, external PCoIP does not work. Can I open a session in the 5.2 Client view, see the list of office pools, select a pool, the desk at work close and try to open remotely. After 1 second, this error appears:

  Error: Overview of VMware View Client: The connection to the remote computer has ended.

  What does not work:

  • External/WAN via PCoIP for workstations with the view Agent 5.2.0

  What does not work:

  • Internal/LAN via PCoIP for workstations with the view Agent 5.2.0
  • Internal/LAN via RDP for workstations with the view Agent 5.2.0
  • External/WAN via RDP for workstations with the view Agent 5.2.0
  • External/WAN via PCoIP for workstations with the Agent View 5.1.3 or lower (tested up to 4.6.0 Agent view)

  I even tried to build a new pool of desktop Windows 7 in a new OU in the active without optimizations VDI directory or group policy. I tried with and without the firewall Windows is activated. In any case, this new office pool works externally via any Agent from view but the view Agent 5.2.0.

  Is it the 5.2.0 Agent view have the same firewall/port that the Agent View 5.1.3 requirements? What else can I test or try to get external PCoIP for desktop computers to work with the view Agent 5.2.0?

  Finally, we discovered the problem / solution. We on a security apparatus of Palo Alto Networks that blocked traffic PCoIP 5.2.0 but not PCoIP 5.1.3 traffic.

  According to a backline Vmware engineer:

  "A change was made to the ephemeral TLS connection that is used to establish trust and to negotiate parameters for subsequent UDP traffic network. This change allows the customer to use their own certificate for TLS server for this connection. For more details of what happens during the installation of PCoIP, and how this changed view 5.2, see KB 1038762. »

  It seems that Palo Alto Networks did not like this change. When we removed our Palo Alto of WAN device, PCoIP 5.2.0 connections could be created. We finally had create a rule to allow the category: private-ip-addresses and URL: pcoip - by default-sni. Once this change has been made, connections WAN PCoIP 5.2.0 started working.

• Problemas con vmware view 4.1 y terminales EVGA 'pcoip '.

  Hola todos,

  I hope to be escuentren very well

  Tengo una consulta en mi tengo vmware virtual center 4.1 entorno y vmware view 4.6

  Estoy put changing Terminal wyse working RDP por q a q el performance pcoip terminals are mucho mejor

  Tengo problemas con some las teminales cuando intentan a1 pcoip an Office Máquinas con esta version of vmware tools "vmware, Inc. product version: 8.3.17.15269, en todas estoy using esta version of officer discovers 4.6.0.366101.

  El problema're q despues el usuario type is the clave para a1 al servidor view appears una pantalla negra como por 5 segundos y despues devuelva has the pantalla inicio donde No. conectamos con el conexion server.

  If yo misma pcoip terminal uso para conectarme a otra Máquina virtual q tiene otra lower vm tools version has the 8.3.17.15269 TR conecta sin problemas. por lo q the diff q veo unica are the vmtools una Máquina a otra... pero todas no is como eso porq I have did a cluster con unas 60 vm con esa version of vm tools. Esto solo pasa con las pcoip terminals porq TR uso una wyse normal con esta version of vm tools 8.3.17.15269 if works

  Saludos,

  Hola Warrenjc

  Te cuento than amendments nosotros y paso el tema esta originado in el orden en what instalan drivers, vmware tools y officer see.

  Well as h. para y no tengas problemas you recommend respetes a raja tabla el orden of deployment of same segun lo indica vmw.

  ES decir.

  1. Instalar the vm.
  2. Instalar vmware tools.
  3. Agent view instalar.

  Fijate if asi you works adecuadamente.

  If haces algun cambio a nivel parches, plots etc, to be replaced by Recomiendan desinstalar todos los compontentes y volver a instalarlos en orden.

  Espero esto resuelva you question.

  Diego Quintana

• Automation of VMWare View with PCOIP 5.0

  Hello

  I am trying to automate the execution of applications in VMWare View Client (PCOIP). However, I'm stuck with sending the keys to applications. I tried in vain on the keyboard to screen, SendKeys, keyboard hook to this effect. I also read VIX API documentation but I don't think that it works for me because I don't have administrator rights. Please notify.

  Kind regards

  Amjad Ali

  I'm not sure I understand the question either, but I had some success using AutoIT (http://www.autoitscript.com/site/autoit/) for automation in the past. Using this, you can compile a script as an executable to run in the virtual machine.

  If you do not have rights admin on the virtual machine, you can still use the Run value in the registry for the current user to start an application when you connect. Have you tried to put the path to the executable file that you are trying to launch in the HKCU\Software\Microsoft\Windows\CurrentVersion\Run?

  You might be able to use both of these ideas and set the path to an AutoIT executable in the HKCU Run key to get the automation level you are looking for.

  Dave

• Two monitors configured using PCoIP does not cover both monitors for VMware View

  Occasionally, I've experienced the symptoms described in KB1027899, when usually the first time of connection for the day that I select multiscreen and the screen is divided in the Middle the 2 monitors using PCoIP. I end up disconnecting and reconnecting to the virtual machine a few times, which is a valid solution, but I'm still curious about why this is happening.

  I am running VMware View 5.0.0 build-481677, on a Wyse R90L with Windows XP Embedded, I use VMware View Client 5.0.0 build 481677 and VMWare View agent on a box of Windows 7 5.0.0 build 481677. We lack vCenter and ESXi 5.0.0 in all areas as well.

  According to the article, this happens because there is not enough video memory configured for the virtual computer. The problem I have is that if I force the pool offices use PCoIP and 128 MB of video memory, I can't RDP to the workstation as the Protocol is locked, I need to still be able to do. I tried manually increase the memory video, but view reconfigures to match the settings of the pool.

  Is there a way to increase the video memory without changing the required logon Protocol? Or is there a fix in a different way to this question?

  Thanks a lot guys.

  Joe

  Have you tried to change the configuration video pool to be 2 monitors with 2560 x # instead of the default resolution to see if that solves the problem?

  Datto

• VMware View 5 PCoIP get a black screen on wide AREA network

  Hello community,

  I got a VMware View 5 Infrastructure with a vCenter Server, a connectionserver of view and some clients such as VMs.

  Internally, everything works - connections PCoIP and RDP do their job very well.

  Know that we want to publish the vDesktops over the WAN. Users must connect to the virtual machines in their laptops or iPad (or iPhone) at home. So, we have configured our firewall to open the IP Wan (194.209.166.xy) to the internal IP (192.168.199.xy). A DNS entry for view.xy.com shows the IP WAN. If the WAN connection to infrastructure display RDP works - but PCoIP connections shows a black screen after 10 to 30 seconds after logon. We never see an interaction of oder break Windows. The screen is black after the logoninformations in the client view.

  We have configured the connectionserver display settings as described in some articles here... 7

  The external url HTTPS: https://view.xy.com

  checkbox activ: tunnel connection secure user desktop

  PCoIP external url: 194.209.166.xy:4172

  checkbox activ: use pcoip gateway secure for pcoip Desktop connections

  We have forgotten to do some settings or is it an another workaround to work with PCoIP over the WAN?

  Kind regards

  Freddie

  Cross video related to the above article. It describes exactly the configuration you are working. If you have any questions on this subject, let us know and someone on this forum will help you.

  Select this option.

• VMware View 4 - PCoIP - scanning is very slow

  When you scan from a USB scanner from a heavy client without VDI, it takes 7 seconds. When you use VMware View with PCoIP 4.0, it takes 52 seconds.

  Any suggestions?

  Rgds

  M

  I sent an email to teradici support and they checked the speed was closer to the USB 1.1 instead of 2.0.   If you PM me your email I'll send you the conversation

  If you have found this device or any other useful post please consider the use of buttons useful/correct to award points

• VMware View customers logout - log for debugging PCoIP shows "sessionDisconnectTimer: set the timer to 2147480 seconds.

  I have operators who are still on my desktop 24/7/365.  Assuming that there are no other problems, they get kicked out of their sessions from view after about 24 days.  We use Thin Clients HP running ThinOS and VMware View Client.  When I check the log for debugging on the Windows 7 VM, I see that when the connection is established, he wrote the following line:

  2014-09-09 08:44:30, 807 DEBUG < MessageFrameWorkDispatch > [wsnm_desktop] sessionDisconnectTimer: set the timer to 2147480 seconds

  After the expiration of the time limit, I get the following messages in the same newspaper and the client disconnects:

  2014-09-09 08:30:08, 571 DEBUG < TimerService > [wsnm_desktop] sessionDisconnectTimer: triggered timer, session is disconnected.

  2014-09-09 08:30:08, 571 DEBUG < TimerService > [wsnm_desktop] session::SessionDisconnectTimedOut: Disconnect message posted on the desktop

  Where it becomes this timer of?  The global setting on the display server is maxed at 9 999 999 minutes.

  The host is EXSi 5.0.0

  VMware View Server is 5.0.0 - 481677

  See Agent 5.0.1

  Operating system is Windows 7 Pro running on the virtual version 7 machine

  It is a known problem that has been fixed in 5.3.2 view - the global time-out in minutes is converted to a time in milliseconds, which then overflows a 32-bit counter. See Overview of VMware View Release Notes

  A desktop session is timeout and be disconnected after about 24 days, 20 hours and 31 minutes, even if the Session time-out setting has been set to a higher value.

  Mike

• Overview of VMware View PCoIP

  Hello

  We have a test lab test view VMware Horizon on a test environment however we find that the following questions.

  When is connected through the vmware view client, enter the user name and then select on the desktop, we find that the following two errors:

  he tries to connect to the desktop computer, then we get a black screen, then a prompt that shows the end of the connection to the remote computer.

  The other mistake that we get is "the Protocol to display for this office is currently unavailable, so if we click try again we get the black screen and then the same error message ended with the connection to the remote computer.

  If we choose RDP, it works.

  This configuration is configured as follows:

  (material f/w)                                      (Win7) (Windows Firewall)

  Client application VMware > > > Firewall > > > > connect to server > > > > Virtual Office

  Firewall hardware ports 443 has sent to the login server

  Hardware firewall has ports open 4172 server to connect to the virtual desktop

  Virtual office has ports open virtual desktop to connect to the server of 4172

  am I missing something?

  What we are seeing with RDP, is that she's bad performance on YouTube and by displaying the web

  Hello

  Looks like your firewall rules are not configured correctly.

  Please refer to this doc and set the rules http://communities.vmware.com/docs/DOC-14974

  Concerning

  Noble

• How to fix VMware View Server certificate revocation check connection error?

  Dear community,

  For about 2 weeks, I feel a revocation of the certificate check error in our environment Horizon see 6.2. The strange thing is that, within 12 hours about two (replication) connection servers and the vCenter Server / server of composer (on the same machine) are considered as having invalid certificates, even if, in fact, they are valid (CA certificates). We use no security servers.

  The view admin console shows the following for servers connection:

  The server certificate is not approved.

  The server certificate cannot be verified.

  For the vCenter, he said (that I have validated manually the certificate):

  No problems found.

  Certificate is not approved, but the thumbprint of the certificate is accepted.

  With the connection series on 'full', States that the login server logs for the vCenter server:

  TRACE (B 17-0 - 0E98) < VCHealthUpdate > [NativeKeyVault] validateCertificateChain response: {result = FAIL, EndEntityReasons = cantCheckRevoked, ChainReasons = invalid, SelfSigned = false, EndErrorCode = 16777280, EndInfoCode = 258, ChainErrorCode = 16777280, ChainInfoCode = 256, PolicyErrorCode =-2146885613}

  As far as I can see there no similar entries for login server certificates in the newspaper.

  At the moment I am under the environment with composer and vCenter certificates manually valid and invalid connection (red) server certificates (as view clients and browsers are not disabled).

  I already checked that I am able to do everything 'green' again via setting the registry key 'CertificateRevocationCheckType'2 (as described here Configure the server certificates certificate revocation check). This brings me to the conclusion that one of the intermediate certificates cannot be validated. So, I had the information a "version" of an intermediate (intermediate certification authority) certificate has been revoked. There seems to be no coincidence - like the time point is as well, but this particular version does not appear to be used in the servers of my connection.

  However, even with full logging enabled, I can't information which (intermediate) certificate cannot be validated and why. I expected to see something like 'OCSP verification' or 'check the CRL' but I can't find it in the newspapers. However, I noticed that one of the intermediate certificates lacked the OCSP URL (even if the field "Authority Information Access" existed). Of course I updated the certificate with a version that contains the OCSP URL, but it has not changed anything.

  In addition, I checked manually all of the certificates in the chain with openssl (for OCSP) and CRLs as well, but everything seems to be OK (all URLS are accessible and no opportunity of certificate has been revoked). Actually, I do not interpret the error as "that the connection to the server is an invalid certificate because it has been revoked", but "it cannot check if it has been revoked. The servers do not need a proxy and nothing configured, so (I checked the proxy settings system context, also).

  For now, the problem is not critical, such as 'red' status connection server has no effect on our customers and so I could turn off certificate revocation check (or switch to check that the certificate of the server (2)). But of course, I would really solve the problem.

  Is there someone who can give me a hint on what to check, for example, how do I know which certificate cannot be controlled and why? Someone had the same or a similar problem? Support VMware is working on the problem as well, but they seem don't know is not the problem, either.

  I appreciate the thoughts and responses! Thank you!

  Best regards

  Fabian

  Dear community,

  During this time, I was able to correct the error described at the beginning of this thread. Jump to the end to see what could probably help you...

  1. At first, I installed an additional standalone VMware View Server connection in order to check the following related certificates:
     1. VMware support always told me to renew my certificates because they "were not valid" etc. - even if in fact they were (like external URL calls and attested manual verification and tests).
     2. That's why I created new additional certificates for the login server and configured to include the vCenter even as my production environment - only difference was I didn't inlcude the composer who runs the server vCenter himself.
     3. The result was that the server was "green" including both the vCenter Server certificate which could be 'not reliable' by the environment of production - strange, huh?
  2. After I reset the additional server to a turned wink where connection to the server was not yet installed (before that, I uninstalled the connection to the server in case there is information in vCenter thereon) and reinstalled as a replica of the production environment server. Somehow I expected this, but still quite strange the vCenter Server (and composer) now again was considered "invalid", even if the certificate of the server connection itself considered still valid and green. For test purposes, so I put certifice revocation checking on '2' (only one server certificate check) - but only on the 'old' production servers' and 'magical' everything has been considered valid. So as I see it, there seems to be some sort of information stored on the 'old' connection servers that makes them believe that invalid certificates and that the information is replicated on the third server unless I lower the revocation of the certificate controls on these servers. Altervative explanation could be that VMware View does not accept certificates with aliases that do not include the 'real' server name - that is / was in fact certificates the old servers connection. The new server certificate connection included the real name and the alias. I understand if this is the case, but then I expect that it be documented somewhere (I have not found this information) and also wouldn't understand why it worked without problem for several years before.
  3. After finding that out, I created new certificates for the 'old' connection servers, including aliases and real names and replaced the certificate on one of the servers (and restarted the login server) - only a few successfully. Once I put the revocation checking on '4' again on this server, the login server certificate was still considered valid, but not the vCenter and certificate of composer.
  4. Now, I've uninstalled the old login server (removed from the view) and reinstalled completely (including an update of the 2008 R2 2012 R2 OS) and after I have it reintegrated into the environment, everything remained green - as long I have will activate revocation checking on the second login server "old." This is why I did the same with this (completely reinstalled and reinstated it) and now everything is green with the revocation checking enabled on all replicas of server connection.
  5. The next step I uninstall the additional replica because I created only for troubleshooting purposes.

  So what will no doubt help in similar cases:

  • Reinstall the servers of connection one by one, including:
  • Uninstalling html access (if used), uninstall the login server to view, uninstall 'VMware' AD LDS Instance.
  • Removal of the connection to the server of replication group: run "s - r s uninstalled_ vdmadmin.exeservername" on one of the servers connection remaining.
  • Reinstall/Update OS (may not be necessary, but I did not test that)
  • Reininstall, return to the login server replica. If you used the certificates which included only the alias of the server I recommend you to create new ones, including the name of the server as well, but maybe it's not necessary as well. If you want to keep the certificates which only inlcude the alias it will be necessary to install this certificate after the first replication of the servers (see below).

  My question for technicians of VMware/developers: It is supported to use certificates include only the server alias. Otherwise why it worked before and where is it documented? Where are certificate cached information so that simply replace the certificate was only some, and not a complete success (see above). FYI - when I paired initially replicas that I had to install the CA (including only the pseudonym) after the first replication - now with certificates (including the server name and the alias), I could install the certificate before you replicate (= the login server installation).