VMware Horizon View 6/7 – Smartcard Authentifizierung aktivieren

Um die Smartcard Authentifizierung des View Connection Servers zu aktivieren sind folgende Schritte notwendig.
Die Authentifizierung per Smartcard ist dann möglich bei Benutzerung von: View Horizon Client, PCoIP / Teradici, aber auch für die Administrationsoberfläche.
Zuerst muss mann ein Java Keystore anlegen in den das Root Zertifikat der eigenen Zertifizierungsstelle importiert wird.
Wenn man ein Zwischenzertifikat (Intermediate) benötigt, muss auch dieses Zertifikate importiert werden. (Einfach Schritt 1 wiederholen).

Schritt 1: Root Zertifikat in Keystore importieren

cd C:\Program Files\VMware\VMware View\Server\jre\bin
keytool.exe -import -alias ZertifikatsBeschreibung -file C:\temp\caRoot-base64.cer -keystore ..\..\sslgateway\conf\trust.key

Jetzt muss ein Passwort für den Keystore festgelegt werden. Das VMware Default Kennwort sollte hier eingetragen werden: secret
Mann kann auch ein eigenes Password wählen, dies muss dann aber auch in der locked.properties Datei eingetragen werden und bringt nicht wirklich eine höhere Sicherheit.Zusätzlich muss man dem angezeigtem, importiertem Zertifikat vertrauen (yes), damit es in den Keystore hinzugefügt wird.

Enter keystore password: secret
Re-enter new password:secret
Owner: your Certificate Information
Issuer: your Certificate Information
Serial number: your Serial Number
Valid from: Sun Jun 20 21:17:18 CEST 2010 until: Wed Jun 20 21:27:17 CEST 2040
Certificate fingerprints:
MD5:  your fingerprints
SHA1: your fingerprints
SHA256: your fingerprints
your fingerprints
Signature algorithm name: SHA1withRSA
Version: 3
Extensions:
#1: ObjectId: 1.3.6.1.4.1.311.21.1 Criticality=false
0000: 02 01 00                                           ...
#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#4: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
.....
]
]
Trust this certificate? [no]:  yes
Certificate was added to keystore

Java Keystore erstellen

Schritt 2: locked.properties anlegen / ergänzen

Jetzt wechseln wir in das folgende Verzeichnis:

C:\Program Files\VMware\VMware View\Server\sslgateway\conf

Dort sollte sich nun unserer Keystore (trust.key) befinden. Damit der View Connection Server weiß, dass er die Datei laden soll, müssen wir nun eine neue Datei anlegen (falls nicht vorhanden) die: locked.properties heißt.
Die Datei mit Notepad editieren und mit folgenden Inhalt füllen:

trustKeyfile=trust.key
trustStoretype=jks
useCertAuth=true

Schritt 3: View Connection Server Service neustarten

Entwerder per CMD:

net stop wsbroker
net start wsbroker

Oder per services.msc
view-restart-service

Schritt 4: Smartcard Authentication innerhalb des View Administrators aktivieren

Nun muss noch im View Administrator die Smartcard Authentication aktiviert werden. Es gibt hier zwei Einstellungsmöglichkeite: Optional und Required. Bei Optional kann man sich wie wie gewohnt per User/Passwort authentifizieren. Wird eine Smartcard erkannt, wird diese aber gewählt. Bei Required ist eine Anmeldung per Smartcard verpflichtend.
Die Einstellung findet man unter: View Configuration -> Servers -> Connection Servers -> Server auswählen -> Edit -> Authentication
view-smartcard
Um zu überprüfen ob alles korrekt ist, kann man im debug log nach „useCertAuth“ suchen. Die Logs liegen unter: „C:\ProgramData\VMware\VDM\logs“

2016-09-16T13:43:50.488+02:00 DEBUG (1F48-1A98) <Front> [e] useCertAuth is configured as: false
2016-09-16T13:43:50.488+02:00 INFO (1F48-1A98) <Front> [e] Smart Card/Certificate Authentication will not be used as useCertAuth is false
bzw.
2016-09-16T14:56:15.505+02:00 DEBUG (1CD0-1D88) <Front> [e] useCertAuth is configured as: true
2016-09-16T14:56:15.505+02:00 INFO (1CD0-1D88) <Front> [e] Smart Card/Certificate Authentication enabled at gateway

Fertig 😉

Vmware Horizon View 7 – Composer – Fix: "Internal View Composer Error"

vmwareviewcomposer
Beim Installieren eines neuen View Composers bin ich auf den folgenden Fehler gestoßen. Ich dachte zuerst an ein Zertifikatsproblem, da in den Logs zuvor SSL sehr oft erwähnt wurde. Bei genauerem hinsehen fällt aber ein „Access Denied“ auf, welches mich dann auf den richtigen Weg brachte.
Hat der Benutzer, welcher für die vCenter Anbindung verwendet wird, die passenden „lokalen“ Rechte auf dem Server ?
In meinem Setup habe ich den View Composer auf dem vCenter Server installiert und verwende Domänen-Benutzer. Ich hatten dem Benutzer volle Administrationsrechte im vCenter gegeben, jedoch keine lokalen Rechte (in Windows).

Lösung:

Also dem Benutzer der auch für den vCenter Zugriff verwendet wird lokale Administrationsrechte gegeben.
Anschließend den View Composer Dienst neustarten und über den View Administrator erneut probieren.
[EXPAND VDM DebugLog]
2016-07-12T15:52:34.598+02:00 DEBUG (0B40-0FA4) <Thread-43> [TrackerObject] Sync complete: DomainHealth:SERVERNAME|DOMAIN to version: 11
2016-07-12T15:52:34.600+02:00 DEBUG (0B40-0FA4) <Thread-43> [TrackerManager] Sending message: (TrackerMessage SYNC {}: {nn=SERVERNAME, u=[{„type“:“SET“,“item“:{„name“:“ATTR_DOMAIN_NAME“,“type“:“STRING“,“stringValue“:“DOMAIN“}},{„type“:“SET“,“item“:{„name“:“ATTR_DOMAIN_DNS“,“type“:“STRING“,…
2016-07-12T15:52:34.794+02:00 DEBUG (0B40-0E4C) <Thread-51> [TrackerObject] Sync complete: certificatessohealth:SERVERNAME to version: 11
2016-07-12T15:52:34.795+02:00 DEBUG (0B40-0E4C) <Thread-51> [TrackerManager] Sending message: (TrackerMessage SYNC {}: {nn=SERVERNAME, u=[{„type“:“SET“,“item“:{„name“:“name“,“type“:“STRING“,“stringValue“:“SERVERNAME“}},{„type“:“SET“,“item“:{„name“:“enrollserverconnection“,“type“:“NVPLIST“,“nvpList…
2016-07-12T15:52:34.795+02:00 DEBUG (0B40-0ED4) <EnhancedSecurityManager$EnhancedSecurityTask-1468330894772> [EnhancedSecurityManager$EnhancedSecurityTask] Current mode: ENHANCED current level: ENHANCED
2016-07-12T15:52:45.905+02:00 DEBUG (0B40-128C) <ajp-nio-8009-exec-4> [CertMatchingTrustManager] Created new CertMatchingTrustManager com.vmware.vdi.ssl.CertMatchingTrustManager@23e07a96 with ThumbprintManager com.vmware.vdi.desktopcontroller.LdapThumbprintManager@4320146b
2016-07-12T15:52:45.906+02:00 DEBUG (0B40-128C) <ajp-nio-8009-exec-4> [HardenedSSLSocketFactory] Creating new HardenedSSLSocketFactory, caller=com.vmware.vdi.ssl.HardenedSSLSocketFactory.<init>(SourceFile:67)
2016-07-12T15:52:45.907+02:00 DEBUG (0B40-128C) <ajp-nio-8009-exec-4> [HardenedSSLSocketFactory] SSL provider: SunJSSE version 1.8
2016-07-12T15:52:45.907+02:00 DEBUG (0B40-128C) <ajp-nio-8009-exec-4> [HardenedSSLSocketFactory] SSL protocol: TLSv1.2
2016-07-12T15:52:45.908+02:00 DEBUG (0B40-128C) <ajp-nio-8009-exec-4> [HardenedSSLSocketFactory] SSL secure protocols (2): [TLSv1.2, TLSv1.1]
2016-07-12T15:52:45.908+02:00 DEBUG (0B40-128C) <ajp-nio-8009-exec-4> [HardenedSSLSocketFactory] SSL cipher suites (6): [TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA]
2016-07-12T15:52:45.953+02:00 DEBUG (0B40-0938) <MessageFrameWorkDispatch> [MessageFrameWork] ValidateCertificateChain ok=1, msecs=0
2016-07-12T15:52:46.046+02:00 DEBUG (0B40-0938) <MessageFrameWorkDispatch> [MessageFrameWork] ValidateCertificateChain ok=1, msecs=0
2016-07-12T15:52:46.806+02:00 DEBUG (0B40-0938) <MessageFrameWorkDispatch> [MessageFrameWork] ValidateCertificateChain ok=1, msecs=0
2016-07-12T15:52:46.834+02:00 DEBUG (0B40-128C) <ajp-nio-8009-exec-4> [ViewFlexFactory] com.vmware.vdi.admin.ui.bean.VCServerBean.validateCertificate 37242 ms
2016-07-12T15:52:46.852+02:00 DEBUG (0D30-1344) <AJP-42> [SimpleAJPService] (ajp:admin:Request16) Response 200 OK
2016-07-12T15:52:53.873+02:00 DEBUG (0D30-1068) <Thread-27> [SimpleAJPService] (ajp:admin:Request17) Request from /10.0.101.55: POST /admin/amfproxy/amfsecure
2016-07-12T15:52:53.875+02:00 DEBUG (0D30-1068) <Thread-27> [SimpleAJPService] (ajp:admin:Request17) Gateway headers sent to the broker:
2016-07-12T15:52:53.875+02:00 DEBUG (0D30-1068) <Thread-27> [SimpleAJPService] (ajp:admin:Request17) gateway-type = [SG-cohosted]
2016-07-12T15:52:53.876+02:00 DEBUG (0D30-1068) <Thread-27> [SimpleAJPService] (ajp:admin:Request17) gateway-location = [Internal]
2016-07-12T15:52:54.585+02:00 DEBUG (0B40-0FB4) <CBHealthUpdate> [TrackerObject] Sync complete: BrokerHealth:SERVERNAME to version: 17
2016-07-12T15:52:54.587+02:00 DEBUG (0B40-0FB4) <CBHealthUpdate> [TrackerManager] Sending message: (TrackerMessage SYNC {}: {nn=SERVERNAME, u=[{„type“:“SET“,“item“:{„name“:“HEALTH_LAST_UPDATE_TIME“,“type“:“LONG“,“longValue“:1468331574585}},{„type“:“SET“,“item“:{„name“:“ATTR_BROKER_VERSION“,“type“:“ST…
2016-07-12T15:52:54.603+02:00 DEBUG (0B40-0938) <MessageFrameWorkDispatch> [MessageFrameWork] ValidateCertificateChain ok=1, msecs=0
2016-07-12T15:52:55.079+02:00 ERROR (0B40-1284) <ajp-nio-8009-exec-2> [VCServerBean] Internal View Composer error. Contact your administrator.
2016-07-12T15:52:55.083+02:00 DEBUG (0B40-1284) <ajp-nio-8009-exec-2> [ViewFlexFactory] Internal View Composer error. Contact your administrator. com.vmware.vdi.admin.ui.common.ViewFlexFactory$ViewProxy.invoke(SourceFile:125)
com.vmware.vdi.admin.ui.common.FlexRemoteException: Internal View Composer error. Contact your administrator.
at com.vmware.vdi.admin.ui.common.FlexFaultHandler.systemError(SourceFile:70)
at com.vmware.vdi.admin.ui.bean.VCServerBean.validateViewComposerCertificate(SourceFile:1758)
at com.vmware.vdi.admin.ui.bean.VCServerBean.validateViewComposerCertificate(SourceFile:1710)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.vmware.vdi.admin.ui.common.ViewFlexFactory$ViewProxy.invoke(SourceFile:113)
at com.sun.proxy.$Proxy60.validateViewComposerCertificate(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at flex.messaging.services.remoting.adapters.JavaAdapter.invoke(JavaAdapter.java:386)
at flex.messaging.services.RemotingService.serviceMessage(RemotingService.java:178)
at flex.messaging.MessageBroker.routeMessageToService(MessageBroker.java:1468)
at flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:1044)
at flex.messaging.endpoints.amf.MessageBrokerFilter.invoke(MessageBrokerFilter.java:101)
at flex.messaging.endpoints.amf.LegacyFilter.invoke(LegacyFilter.java:154)
at flex.messaging.endpoints.amf.SessionFilter.invoke(SessionFilter.java:42)
at flex.messaging.endpoints.amf.BatchProcessFilter.invoke(BatchProcessFilter.java:63)
at flex.messaging.endpoints.amf.SerializationFilter.invoke(SerializationFilter.java:190)
at flex.messaging.endpoints.BaseHTTPEndpoint.service(BaseHTTPEndpoint.java:328)
at flex.messaging.MessageBrokerServlet.service(MessageBrokerServlet.java:373)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:720)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:466)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:391)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:318)
at com.vmware.vdi.admin.ui.servlet.AMFProxyServlet.a(SourceFile:90)
at com.vmware.vdi.admin.ui.servlet.AMFProxyServlet.doPost(SourceFile:57)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.catalina.filters.FailedRequestFilter.doFilter(FailedRequestFilter.java:97)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at com.vmware.vdi.support.ViewAdminFilter.doFilter(SourceFile:103)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at com.vmware.vdi.admin.be.filters.CertificateAuthFilter.doFilter(SourceFile:140)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at com.vmware.vdi.admin.be.filters.DisableUrlSessionFilter.doFilter(SourceFile:73)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)
at org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:868)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1502)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1458)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: Access is denied.
at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at com.vmware.SviService.Admin.v3_5.Binding.SslBasicAuthEndpointStub.getVersion(SslBasicAuthEndpointStub.java:2015)
at com.vmware.vdi.svisupport.SVIConnection.testConnection(SourceFile:147)
at com.vmware.vdi.admin.be.VCManager.validateSVICert(SourceFile:1235)
at com.vmware.vdi.admin.ui.bean.VCServerBean.validateViewComposerCertificate(SourceFile:1740)
… 61 more
2016-07-12T15:52:55.083+02:00 DEBUG (0B40-1284) <ajp-nio-8009-exec-2> [ViewFlexFactory] com.vmware.vdi.admin.ui.bean.VCServerBean.validateViewComposerCertificate 1201 ms
2016-07-12T15:52:55.153+02:00 DEBUG (0D30-1300) <AJP-25> [SimpleAJPService] (ajp:admin:Request17) Response 200 OK
2016-07-12T15:53:30.182+02:00 DEBUG (0D30-0E80) <MsgWorker#5> [bm] Item on queue „Inbound JMS Worker“ for 55 us, queue length = 0, available workers = 9 of 10
2016-07-12T15:53:30.182+02:00 DEBUG (0D30-0E80) <MsgWorker#5> [r] (-) RequestGetStatus: serverType = ice, server = null, localHostname = SERVERNAME
2016-07-12T15:53:30.183+02:00 DEBUG (0D30-0E80) <MsgWorker#5> [cc] (-) Queuing request ABSGC29-b
2016-07-12T15:53:30.183+02:00 DEBUG (0D30-1008) <ABSGC29> [cc] Handling request ABSGC29-b, on queue for 33uS
2016-07-12T15:53:30.186+02:00 DEBUG (0D30-1008) <ABSGC29> [cc] Queuing receipt ABSGC-11
2016-07-12T15:53:30.186+02:00 DEBUG (0D30-1180) <ABSGC29:C> [cm] Handling message ABSGC-11, on queue for 28uS
2016-07-12T15:53:30.186+02:00 DEBUG (0D30-0E80) <MsgWorker#5> [cs] (-) Queuing request PSGC28-10
2016-07-12T15:53:30.186+02:00 DEBUG (0D30-100C) <PSGC28> [cs] Handling request PSGC28-10, on queue for 26uS
2016-07-12T15:53:30.186+02:00 DEBUG (0D30-100C) <PSGC28> [cs] Sending GETCOUNTERS request PSGC28-10
[/EXPAND]

Vmware View Horizon 7 – SSL Zertifikat austauschen

Für ein Testsystem habe ich den neuen View Horizon 7 Connection Server installiert und wollte das selbstsignierte Zertifikat durch ein Zertifikat der Windows CA austauschen.
Normalerweise hat es immer geklappt über die MMC einfach ein neues Computerzertifikat zu erzeugen, und den Friendly Name umzusetzen.
Jedoch bekam ich diesmal folgende Fehlermeldung:

2016-07-12T08:44:31.019+02:00 INFO (1188-0C10) &lt;Thread-1&gt; [v] The Secure Gateway Server is checking for connection attempts on http://*, port:80
2016-07-12T08:44:31.065+02:00 INFO (1188-0C10) &lt;Thread-1&gt; [v] The Secure Gateway Server is using SSL certificate store of type KeyVault
2016-07-12T08:44:31.065+02:00 WARN (1188-0C10) &lt;Thread-1&gt; [KeyVaultKeyStore] (NetHandler) Failed to get certificate chain for: "vdm"
2016-07-12T08:44:31.065+02:00 WARN (1188-0C10) &lt;Thread-1&gt; [KeyVaultKeyStore] (NetHandler) Certificate chain not found for alias: vdm
2016-07-12T08:44:31.081+02:00 INFO (1188-0C10) &lt;Thread-1&gt; [v] The Secure Gateway Server is listening on https://*, port:443
....
2016-07-12T08:46:22.939+02:00 ERROR (1188-1AE4) &lt;pool-1-thread-1&gt; [KeyVaultKeyStore] (NetHandler) No qualifying certificates in keystore
2016-07-12T08:46:22.940+02:00 ERROR (1188-1AE4) &lt;pool-1-thread-1&gt; [KeyVaultKeyStore] (NetHandler) No qualifying certificates in keystore
2016-07-12T08:46:22.941+02:00 ERROR (1188-1AE4) &lt;pool-1-thread-1&gt; [KeyVaultKeyStore] (NetHandler) No qualifying certificates in keystore
2016-07-12T08:46:22.942+02:00 ERROR (1188-1AE4) &lt;pool-1-thread-1&gt; [KeyVaultKeyStore] (NetHandler) No qualifying certificates in keystore
2016-07-12T08:46:22.963+02:00 ERROR (1188-0938) &lt;pool-1-thread-2&gt; [KeyVaultKeyStore] (NetHandler) No qualifying certificates in keystore

Also habe ich nochmal von Hand eine Zertifikatsanforderung mit OpenSSL erstellt:

openssl req -new -sha256 -nodes -newkey rsa:4096 -subj '/C=DE/ST=Hessen/L=Location/O=Company/OU=TEST/CN=server.fqdn.info/emailAddress=support@domain.de/subjectAltName=altFQDN,DNS.1=view.domain.info' &gt; ssl.csr
Generating a 4096 bit RSA private key
....................................................................................................................................................++
..........................................................................................++
writing new private key to 'privkey.pem'
-----

Anschließend über die Windows Zertifizierungsstelle signiert (https://certsrv.domain.info/certsrv/). Als Base64 Zertifikat wieder herunterladen und ein PFX generieren:

openssl pkcs12 -export -in certnew.cer -inkey privkey.pem -out cert.pfx
Enter Export Password:
Verifying - Enter Export Password:

Anschließend das Zertifikat über die MMC (Certificates) in den Personal Zertifikatsspeicher importieren.
Vmware View erstellt automatisch ein selbst signiertes Zertifikat, welches den Friendly Name „vdm“ trägt. Dieser muss umbenannt werden, z.b. „vdm-original“.
Bei dem eigenen Zertifikat muss dann der Friendly Name „vdm“ über (Rechtsklick – Properties) gesetzt werden.
friendlycertname
Anschließend den „Vmware View Connection Server“ Dienst neustarten.
img_001

Cacti Template: VMware View Sessions monitoren

View Administrator StatusWie vielleicht so manche Beiträge hier vermuten lassen, setze ich VMware Horizon View zur Desktopbereitstellung ein. So hat sich mir die Frage gestellt ob man nicht die Anzahl an Connections, gestarteten Desktops etc. im MRTG bzw. Cacti überwachen kann.
Eine kleine Übersicht hat man ja im View Administrator an der linken Seite – aber das hilft einem ja auch nicht weiter um Boot Storms, wie z.B. jeden Morgen um 8 zu dokumentieren.
So bin ich über einen Beitrag in den VMware Communities gestolpert, der Zeigt wie man Session Informationen via typeperf absaugen kann. Funktioniert so aber leider erstmal nur, wenn der Monitoringserver unter einem Windows-Betriebssystem läuft. Aber wer hat das schon 🙂
Hier eine kleine Übersicht der 3 Graphen:


Über check_nrpe ist es möglich Scripte mehr oder weniger OS-Unabhängig auszuführen, bzw. eine passende Antwort zu erhalten.  Somit funktioniert das Template unter Linux & Windows.

    1. Wenn das Monitoringsystem ein Linux z.b. Ubuntu ist, dann muss check_nrpe installiert werden um Befehle an andere Systeme senden zu können. Simple Anleitung hatte ich schon mal letztes Jahr geschrieben, ist immer noch gültig.
    2. Anschließend muss auf dem View Connection Server der Nsclient installiert werden. Download hier.
    3. Nach der Installation muss die nsclient.ini im Programmverzeichnis angepasst werden, sodass  Befehle vom Monitoringserver entgegen genommen werden:
      [/modules]
      ;Check External Scripts - A simple wrapper to run external scripts and batch files.
      CheckExternalScripts = 1
      [/settings/NRPE/server]
      allow arguments=true
      allow nasty characters=true
      [/settings/default]
      ;ALLOWED HOSTS - A comaseparated list of allowed hosts. You can use netmasks (/ syntax) or * to create ranges.
      allowed hosts = CactiIP
      [/settings/external scripts]
      allow arguments=true
      allow nasty characters=true
      [/settings/external scripts/scripts]
      viewstatus = cmd /c echo scripts\view_status.ps1 $ARG1$ $ARG2$; exit($lastexitcode) | powershell.exe -command -

      [stextbox id=“info“]Info: Nach Konfigänderung muss der Nsclient neugestartet werden.
      (net stop nscp && net start nscp)[/stextbox]

    4. Das view_status.ps1 Script im NSClient\scripts Verzeichnis ablegen.
    5. Vom Cacti aus testen:
      /usr/local/nagios/libexec/check_nrpe -H SERVERNAME -c viewstatus -a SERVERNAME "\\SERVERNAME\VMware VDM\*"

      Sollte keine korrekte Ausgabe erfolgen, kann man das Logfile vom nsclient checken: nsclient.log

    6. Im Cacti: Import Templates und das cacti_host_template_vmware_view_connection_server.xml auswählen.
    7. Neuen Host anlegen und das Template „View Connection Server“ zuweisen.
    8. Anschließend auf Create Graphs und die 3 Möglichen Graphen auswählen.
    9. Das Feld Servername muss den Servername enthalten. Die Typeperf Query wäre dann „\\Servername\VMware VDM\*“. (Mit den Anführungszeichen)
      [stextbox id=“info“]Info: Der Servername muss in beiden Feldern komplett Identisch sein, sonst funktioniert das Abschneiden des Strings nicht korrekt.[/stextbox]
    10. Nun den Host im Graph Tree hinzufügen und es werde bunt.


Wenn man Cacti auf einem Windows-Server laufen hat, muss man den Scriptpfad der Datenquelle etwas abändern:
DataInput
Der Pfad müsste auf etwas wie

cmd /c echo scripts\view_status.ps1 &lt;comp&gt; &lt;query&gt;; exit($lastexitcode) | powershell.exe -command - 

abgeändert werde. Ich habe es unter Windows aber nicht getestet und bin auf eure Kommentare gespannt 😉
Download: Cacti-View-Template.zip (v 1.0)

VMware SSL Certificate Automation Tool – fails at vCenter Server

Früher setzte VMware noch mehr auf selbst erstellte Zertifikate zur Absicherung der vielen verschiedenen Serverdiensten. Doch mittlerweile ist für viele wie z.B. VMware Horizon View ein von einer Zertifizierungsstelle erzeugtes Zertifikat notwendig. Fängt man einmal mit dem Signieren an kommt man auch nicht mehr groß um die anderen Dienste herum. ESXi Server, vCenter Server, SSO Server, Update Manager, Inventory Dienst, Site Recovery Manager und noch viele mehr können bzw. müssen dementsprechend auch mit eigenen Zertifikaten versorgt werden.
Um dem Chaos etwas entgegen zu wirken hat VMware ein kleines Kommandozeilentool veröffentlicht – das VMware SSL Certificate Automation Tool. Momentan in der Version 1.0.1 bei VMware verfügbar.
2044696-examplecsr
 
Beim Updaten des vCenter Server Zertifikats bin ich auf folgenden Fehler gestoßen:

[19.06.2013 - 10:48:11,31]: ""Cannot reload the vCenter Server SSL certificates. The certificate might not be unique.""
[19.06.2013 - 10:48:11,31]: Deleting the new certificates and keys...
[19.06.2013 - 10:48:11,33]: Restoring the original certificates and keys...
1 file(s) copied.
1 file(s) copied.
1 file(s) copied.
[19.06.2013 - 10:48:11,36]: The vCenter certificate update failed.

[Expand Vollständiges Log]
[19.06.2013 – 10:48:04,48]: Validating Lookup Service connection
Intializing registration provider…
Getting SSL certificates for https://server.domain.info:7444/lookupservice/sdk
Getting SSL certificates for https://server.domain.info:7444/sso-adminserver/sdk
Getting SSL certificates for https://server.domain.info:7444/ims/STSService?wsdl
Successfully created dummy service, we have sufficient privileges
Successfully deleted dummy service, we have sufficient privileges
The file C:\tool\backup\VC\ROOT_LS_SSL_CHAIN.crt already exists. Overwriting…
The file C:\tool\backup\VC\1_LS_SSL_CHAIN.crt already exists. Overwriting…
Certificates saved successfully
Return code is: Success
[19.06.2013 – 10:48:09,05]: Cleaning any temporary files
[19.06.2013 – 10:48:09,05]: Backing up the certificates and keys from „C:\ProgramData\VMware\VMware VirtualCenter\SSL…“
1 file(s) copied.
1 file(s) copied.
1 file(s) copied.
[19.06.2013 – 10:48:09,08]: Copying the new certificates and keys to „C:\ProgramData\VMware\VMware VirtualCenter\SSL…“
[19.06.2013 – 10:48:09,10]: Creating the PKCS certificate file…
Could not reload vCenter SSL Certificates
[19.06.2013 – 10:48:10,35]: „“Cannot reload the vCenter Server SSL certificates. The certificate might not be unique.““
[19.06.2013 – 10:48:10,36]: Deleting the new certificates and keys…
[19.06.2013 – 10:48:10,36]: Restoring the original certificates and keys…
1 file(s) copied.
1 file(s) copied.
1 file(s) copied.
[19.06.2013 – 10:48:10,41]: Attempting rollback…
Could not reload vCenter SSL Certificates
[19.06.2013 – 10:48:11,31]: „“Cannot reload the vCenter Server SSL certificates. The certificate might not be unique.““
[19.06.2013 – 10:48:11,31]: Deleting the new certificates and keys…
[19.06.2013 – 10:48:11,33]: Restoring the original certificates and keys…
1 file(s) copied.
1 file(s) copied.
1 file(s) copied.
[19.06.2013 – 10:48:11,36]: The vCenter certificate update failed.
[/Expand]
Bei der Ursachenforschung bin ich auf einen hilfreichen Post in der Community gestoßen. Dort wird beschrieben, dass das Problem offenbar an einer fehlerhaften Zuordnung des LookupService mit dem vCenter liegt.
Behoben werden kann der Fehler durch das einsetzen der korrekten ID des LookupService in die vpxd.cfg des vCenter Servers.
Hier die Anleitung:

Steps:
1. Stop vCenter service
2. Look for your ID in LS_ServiceID.prop in folder C:\ProgramData\VMware\VMware VirtualCenter
3. Copy this ID (e.g. {C4672589-9258-42B1-90E2-1EF268BBD402}:5 )
4. Edit your vpxd.cfg in the same folder and replace
&lt;serviceId&gt;vCenterService&lt;/serviceId&gt;
with
&lt;serviceId&gt;your ID&lt;/serviceId&gt;
5. Start vCenter Service
Then the SSL automation tool works!
You don't need to revert the changes.

Anschließend hat auch das Updaten des Zertifikates mittels des SSL Certificate Automation Tool geklappt.
[Expand Komplettes Logfile]
#####################################
[19.06.2013 – 11:00:22,03]: Validating Lookup Service connection
Intializing registration provider…
Getting SSL certificates for https://server.domain.info:7444/lookupservice/sdk
Getting SSL certificates for https://server.domain.info:7444/sso-adminserver/sdk
Getting SSL certificates for https://server.domain.info:7444/ims/STSService?wsdl
Successfully created dummy service, we have sufficient privileges
Successfully deleted dummy service, we have sufficient privileges
The file C:\tool\backup\VC\ROOT_LS_SSL_CHAIN.crt already exists. Overwriting…
The file C:\tool\backup\VC\1_LS_SSL_CHAIN.crt already exists. Overwriting…
Certificates saved successfully
Return code is: Success
[19.06.2013 – 11:00:26,72]: Cleaning any temporary files
[19.06.2013 – 11:00:26,75]: Backing up the certificates and keys from „C:\ProgramData\VMware\VMware VirtualCenter\SSL…“
1 file(s) copied.
1 file(s) copied.
1 file(s) copied.
[19.06.2013 – 11:00:26,77]: Copying the new certificates and keys to „C:\ProgramData\VMware\VMware VirtualCenter\SSL…“
[19.06.2013 – 11:00:26,80]: Creating the PKCS certificate file…
Successfully reloaded vCenter SSL Certificates
[19.06.2013 – 11:00:31,98]: Encrypting the password with the certificates…
—— In-memory logs start ——–
mem> 2013-06-19T11:00:32.172+02:00 [04384 info ‚Hooks‘] Hooks Initialized
—— In-memory logs end ——–
2013-06-19T11:00:32.187+02:00 [04384 info ‚Default‘] Logging uses fast path: true
2013-06-19T11:00:32.187+02:00 [04384 info ‚Default‘] Handling bora/lib logs with VmaCore facilities
2013-06-19T11:00:32.187+02:00 [04384 info ‚Default‘] Initialized channel manager
2013-06-19T11:00:32.187+02:00 [04384 info ‚Default‘] Current working directory: C:\tool
2013-06-19T11:00:32.187+02:00 [04384 info ‚Default‘] ThreadPool windowsStackImmediateCommit = true
2013-06-19T11:00:32.187+02:00 [04384 info ‚ThreadPool‘] Thread enlisted
2013-06-19T11:00:32.187+02:00 [04384 info ‚Default‘] Log path: C:\ProgramData\VMware\VMware VirtualCenter\Logs
2013-06-19T11:00:32.187+02:00 [04384 info ‚Default‘] Initializing SSL
2013-06-19T11:00:33.248+02:00 [04384 info ‚Default‘] Vmacore::InitSSL: handshakeTimeoutUs = 120000000
2013-06-19T11:00:33.248+02:00 [06172 info ‚ThreadPool‘] Thread enlisted
2013-06-19T11:00:33.264+02:00 [04384 info ‚Default‘] Reset DB password succeeded.
[19.06.2013 – 11:00:33,26]: Setup complete. Restarting services…
[19.06.2013 – 11:00:33,27]: Restarting vCenter Server…
SERVICE_NAME: vctomcat
TYPE : 10 WIN32_OWN_PROCESS
STATE : 3 STOP_PENDING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x17
WAIT_HINT : 0x0
[19.06.2013 – 11:00:33,29]: Stopping vCenter Web Services…
[19.06.2013 – 11:00:33,31]: „“Cannot stop the vCenter Server Web Services: 1″“
STATE : 1 STOPPED
SERVICE_NAME: vpxd
TYPE : 10 WIN32_OWN_PROCESS
STATE : 3 STOP_PENDING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x124f80
[19.06.2013 – 11:00:38,19]: Stopping vCenter Server…
[19.06.2013 – 11:00:38,22]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:00:43,15]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:00:48,19]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:00:53,15]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:00:58,20]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:01:03,15]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:01:08,19]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:01:13,22]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:01:18,17]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:01:23,22]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:01:28,18]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:01:33,22]: „“Cannot stop vCenter Server: 1″“
[19.06.2013 – 11:01:38,17]: „“Cannot stop vCenter Server: 1″“
STATE : 1 STOPPED
SERVICE_NAME: vpxd
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x124f80
PID : 4616
FLAGS :
[19.06.2013 – 11:01:43,36]: Starting vCenter Server…
[19.06.2013 – 11:01:43,38]: „“Cannot start vCenter Server: 1″“
[19.06.2013 – 11:01:48,14]: „“Cannot start vCenter Server: 1″“
[19.06.2013 – 11:01:53,17]: „“Cannot start vCenter Server: 1″“
STATE : 4 RUNNING
SERVICE_NAME: vctomcat
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x7d0
PID : 6168
FLAGS :
[19.06.2013 – 11:01:58,24]: Restarting vSphere Profile-Driven Storage Service…
SERVICE_NAME: vimPBSM
TYPE : 10 WIN32_OWN_PROCESS
STATE : 3 STOP_PENDING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x3f
WAIT_HINT : 0x0
[19.06.2013 – 11:01:58,27]: „“Cannot stop vSphere Profile-Driven Storage Service: 1″“
STATE : 1 STOPPED
SERVICE_NAME: vimPBSM
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x7d0
PID : 4644
FLAGS :
[19.06.2013 – 11:02:03,24]: vCenter certificates updated.
[/Expand]
 

VMware View – VM Status: "bereits verwendet" bzw. "already used" beheben

VMWare-View2Seit VMware (Horizon) View 5.1.2 bzw. 5.2 gibt es ein neues Feature zum Umgang mit Virtuellen Maschinen im Status „already used“ bzw. „bereits verwendet“.
Wird ein Benutzer nicht korrekt abgemeldet oder die Aufräumarbeiten des View Agent nicht erfolgreich abgeschlossen wird eine Virtuelle Maschine automatisch in diesen Status versetzt.
Dies ist ein Sicherheitsfeatures, welches nur aktiv ist, wenn bei dem betreffendem Pool die Einstellung „Delete or refresh desktop on logoff“ auf Delete oder Refresh gesetzt ist.
Das Problem an der Sache, dass (warum auch immer) Virtuelle Maschinen im Status „bereits verwendet“ zu angeschalteten bzw. zur Gruppe der verfügbaren VM’s zählt. Dadurch passiert es schnell, dass keine VM anmeldebereit ist aber auch keine weitere mehr angeschaltet wird, obwohl eigentlich noch genügend VM’s (ausgeschaltet) bereitgestellt sind.
Jedenfalls kann man sich jetzt Abhilfe schaffen indem man für seine Pool’s die neu eingeführte „Dirty VM Policy“ benutzt. Dies ist eine ADAM Regel welche über das Setzen des LDAP-Attributes „pae-DirtyVmPolicy“ bei dem entsprechendem Pool greift.
Die Regel greift nur wenn:

A. The desktop session has ended
B. There are no active session either ‘Connected’ or ‘Disconnected’
C. The VM has been marked as ‘dirty’. A VM is marked as ‘dirty’, once a connection has been made to it at least once.

Es gibt 3 mögliche Optionen, wie mit den VM’s umgegangen werden soll:
1. Block access and keep for manual cleanup

By default, the Dirty VM policy will be unset, and the pae-DirtyVMPolicy will have a value ‘0’. Any
‘Single use pool’ VM that skipped the clean-up action because of any reason will be marked as
‘Already Used’
This is recommended for scenarios where administrators do not wish to allow users to get to each
other's data, but also to protect the VMs from data loss in case something does go wrong.

2. Ignore the previous usage and allow access

To ignore the previous VM usage and make it as change the pae-DirtyVMPolicy to ‘1’. With this
configuration and any single use pool VM that misses the cleanup action will be declared as available,
and will allow access to upcoming desktop launch requests.
This is recommended for administrators those who don’t care about the occasional user profile
overlap. This way Administrator can maximize the usage of the pool

3. Forcefully cleanup and declare as available

To perform an aggressive cleanup action (delete or refresh the VM as configured for the pool); set the
pae-DirtyVMPolicy valure to ‘2’. This will ensure no VMs left as “Already Used” and address the user
profile /data overlap issues when gets assigned to another user.
This is recommended for administrators who decide to automatically cleaning up a VM where
something have gone wrong may mean the loss of important logs/data but value maximum pool usage
higher.

dirtyVmpolicy

VMware ESXi 5 Server mit Cacti überwachen

Vorab – dazu gibt es schon einen Beitrag und zwar vom Ersteller des Templates Nitro bzw. Hypervisor.fr
Wie die Domainendung schon zu vermuten gibt aber leider in Französisch. Ich übersetzte die Anleitung sozusagen nur grob und funktional 🙂
Cacti ist die Monitoringsoftware schlecht hin. Wer sich mit MRTG auseinandergesetzt hat wird es kennen, stundenlang in Konfigurationsdateien herum zu editieren. Da ist Cacti doch eine wesentlich ansprechendere, schnellere, und einfachere Lösung.
Natürlich versucht man alle wichtigen Systeme im Monitoring zu haben. Wie man den ESXi Server auch in die Nagios bzw. Centreon Überwachung aufnehmen kann habe ich euch bereits hier beschrieben. Die Methode ist die Gleiche – basierend auf der vSphere Perl SDK und des check_vmware_api Script.
1. Voraussetzungen
Ihr benötigt die VMware vSphere Perl SDK, sowie die notwendigen Perl Module etc. um das check_vmware_api Script zum Laufen zu bekommen.
Wie das geht, habe ich euch hier in einem separatem Beitrag bereits beschrieben.
Seit ihr soweit dass ihr das Script von Hand laufen lassen könnt, gehts hier weiter.
2. vi_host Paket herunterladen:
http://files.hypervisor.fr/scripts/check_vmware_api.zip
3. Die beiden Dateien müssen in das Cacti Script_Queries Verzeichnis kopiert werden. – Standard ist /var/www/cacti/resource/script_queries/

check_vmware_cluster.xml
check_vmware_datastore.xml

4. Die Datei check_esx3_helper.sh muss in das Verzeichnis kopiert werden:

/var/www/cacti/scripts

5. Nun das check_vmware_api Script von op5 herunterladen und ebenfalls in das Verzeichnis kopieren:

/var/www/cacti/scripts

6. Die beiden anderen Dateien importiert ihr ins Cacti:

cacti_data_query_vmware_vpx_-_cluster_usage.xml
cacti_data_query_vmware_vpx_-_vmfs_usage.xml

import-template-cacti-esxi
7. Nachdem nun die Templates importiert sind, müssen diese mit dem vCenter verknüpft werden:
cacti_host_view
8. Logindaten fürs vSphere eingeben
Die Anmeldeinformationen werden anhand der SNMP v3 Logindaten ausgelesen. Sollte man also sein vCenter Server bereits via SNMP überwachen, dann muss man im Cacti dafür ein extra Gerät anlegen, damit man beide SNMP Einstellungen benutzten kann.
snmp-v3-cacti
9. Anschließend die Graphen erstellen:
cacti_graph_view
10. Rundum sollte es dann nach einer Zeit so aussehen:
cacti_cluster_view
Die Bilder sind teilweise kopiert von: http://www.hypervisor.fr/?p=3896

Error 29102 – VMware vCenter 5.1 Upgrade

Beim Upgrade des vCenter von Version 5.0 auf die aktuelle Version 5.1 Update 1 sind wir auf folgenden Fehler gestoßen:

Error 29102. Could not contact Lookup Service. Check VM_ssoreg.log in system teporary folder for details

vcenter-update-error
 
Im Log konnte man nur herauslesen, dass der Installer beim Registrieren mit dem SSO Server in einen Timeout läuft.
Also überprüfen ob die beiden Dienste laufen:
– VMware vCenter Inventory Service
– vCenter Single Sign On
Überprüfen ob die Dienste erreichbar sind:
Single Sign On: https://SSO_host_FQDN_or_IP:7444/lookupservice/sdk
Inventory Service: https://vCenter_host_FQDN_or_IP:10443/
In meinem Fall lief der Inventory Service einfach nicht. Dienst gestartet und das Setup erneut durchgeführt. Erfolgreich 😉