I have got an issue after I have restarted my vCenter VM in my ESXi Host. The error says:
[400] An error occurred while sending an authentication request to the vCenter Single Sign-On server - An error occurred when processing the metadata during vCenter Single Sign-On setup - Failed to connect to VMware Lookup Service - https://10.20.30.50:443/lookupservice/sdk
I tried to find something googling but unfortunately, I couldn't find anything...
Could someone please help me? I can't believe, that just a restart can provide this kind of issues... :(
https://kb.vmware.com/s/article/71387
This is an expected behavior.
VMware vSphere 7.0 enforce FQDN or IP address reverse resolvable to FQDN to allow authentication for Single-Sign on.
There is a problem with the vCenter's service discovery and the vSphere Client basically cannot find its authentication service.
Try to restart VMware Lookup Service from the vCenter Server Management UI (the one on port 5480), subsection Services. If the problem persists, check the lookup service logs. If running the vCenter appliance and not Windows, they should be somewhere under /var/log/vmware...
Have you changed fundamental configuration of vCenter before restart e.g. changing the vCenter host name or root certificates?
Did you contact VMware support?
Related
I did a fresh installation of curity 7.1.0 on a Linux VM. it installed without any issue and started fine. However I am not able to connect it using admin console.
error:
Secure Connection Failed
An error occurred during a connection to xx.xx.xx.xx:6749. PR_CONNECT_RESET_ERROR
A RESET_ERROR often indicates a problem with the infrastructure in my experience.
You can try the following
Clear the cache of your browser
Test with a different browser
Check network settings, i.e. firewall, VPN, proxies, port openings...
I'm currently trying to connect to my Virtual Machine with Windows Server 2012 Datacenter and connect to it via Certification Test Tool 1.2 for Azure. And always getting this error:
Connecting to remote server xyz-vm.westeurope.cloudapp.azure.com
failed with the following error message: WinRM cannot complete the
operation. Verify that the specified computer name is valid, that the
computer is accessible over the network, and that a firewall exception
for the WinRM service is enabled and allows access from this computer.
By default, the WinRM firewall exception for public profiles limits
access to remote computers within the same local subnet. For more
information, see the about_Remote_Troubleshooting Help topic.
I guess the tool is using PSRemot so I checked that:
"winrm" is running.
"PS Remoting" is enabled in the firewall.
Port 5985 and 5986 are in the network security group in Azure and at the local VM Firewall allowed.
I tested the connection via Test-WSMan and I got a connection:
screenshot. But the connection with the Certification Test Tool still failed.
Even after turning the Firewall of the VM completely of, it didn't work
Thank you for your Help
Can you please run in cmd on the Virtual Machine netsh winhttp show proxy
If this shows port 8080 could you then run netsh winhttp reset proxy
According to #Shengbao Shui - MSFT
For a existing VM, you also check this blog. You need create a self-certificate and enable https.
I have a program on my computer that runs as SYSTEM and it is trying to launch an exe(opc server) on a remote machine x.x.x.x. But I get a DCOM error in my machine's eventviewer.
DCOM got error "2147942405" from the computer x.x.x.x when attempting to activate the server: yyyyy
I followed almost all the suggestions on the internet about opening dcomcnfg and adding users limits.default for launch and activation and Everyone,system,interactive,network from link (ftp://ftp.softing.com/pub/outgoing/opc/DCOM/DCOM-Settings-en.pdf) but nothing works.
Would anybody have nay other ideas on how to make this work.
According to MS Technet:
https://social.technet.microsoft.com/Forums/Azure/en-US/8bb5807f-73ba-4092-abc8-283d8fced6c4/request-a-certificate-from-certificate-service-fails-dcom-error-2147942405?forum=winserversecurity
With my VERY limited understanding of Certificate servers you may have one of the scenarios:
Client PC's are trying to connect to a Certificate server that no longer exists
Client PC's have a certificate that is valid but the Certificate server no longer exists
A Certificate server is broken
Clients do not have the proper authority to request the Certificate
I say this is limited knowledge as I am currently trying to remove AD Certificate services from a Domain Controller and I can see that in the System event log the exact same messages are being logged as I have stopped the Certificate services to asses the impact. If I get further information I will post back.
I have a issue on connecting to a clustered sql server instance using wcf-sql adapter.
The sql cluster infrastructure is :
We have 2 servers, SVR1 and SVR2, each have a named SQL instance INST1 installed and these 2 servers are clustered. In SRV1, a clustered MSDTC installed and assigned a NETBIOS name as DTCCLUSTER1. SRV1/SRV2 and DTCCLUSTER1 have its own IP address.
When I try to connect to this SQL Server using WCF-SQL Adapter, I got a timeout error and finally find out this is caused by a MSDTC connection issue. DTCPing test failed in both SRV1 to BizTalk server and BizTalk to SRV1.
The SRV1 hosting DTCCLUSTER1 have been configured to allow both inbound and outbound connections. For security reason, we cannot allow "No Auth" in MSDTC but choosed "Mutual Auth required" in both SRV1 and BizTalk server side.
On server side, the firewall was configured to allow DCE RPC inbound and outbound. We even disabled the firewall in BizTalk server side. Also no port blocking by network.
We are still doing the troubleshooting now, but my question here is kind of more general: what's the proper configuration of the MSDTC for a clustered SQL Server?
For now, there MIGHT be a workaround by setting the UseAmbientTransaction property to false.
Off course, the MSDTC issue is your main concern :)
Are you sure you checked the Network DTC access checkbox as described here:
http://msdn.microsoft.com/en-us/library/dd897483(v=bts.10).aspx
For more information on troubleshooting these specific issues, please see here: http://msdn.microsoft.com/en-us/library/aa561924(v=bts.10).aspx
This link provides you with some good advice on how to set these properties.
More specifically, if you enable the mutual auth required option, take a look at this paragraph:
If either the Mutual Authentication Required or the Incoming Caller
Authentication Required configuration options are enabled then the
client(s) computer account must be granted the Access this computer
from the network user right. If the computer account for a client
computer is not granted the Access this computer from the network user
right, or is included in the Deny access to this computer from the
network user right, then DTC communication between the client and
server computer will fail.
Typically I always set no auth. It might be worth it to try the setting and see if this makes it work. Also be aware that MSDTC settings need to be the same across your BizTalk and SQL servers, including your MSDTC cluster (IIRC: if you have a windows 2008 R2 msdtc cluster).
I have an application that can connect to the Principal, but can't connect to the Mirror during a failover.
(Note to moderator: please let me know if this question is more appropriate for serverfault. I posted it here because I found more questions similar to this issue than on serverfault.)
This is the error I receive when my application attempts to connect to the Mirror after a failover:
Named Pipes Provider: Could not open a connection to SQL Server [53].
Cannot open database "MY_DB_NAME" requested by the login. The login failed.
I am familiar with the fact that when initially connected to the Principal, the name of the Mirror server is cached to be used during the failover and that the failover partner I specify in my connection string is only used if the initial connection to the Principal fails.
This clearly describes the problem I'm having:
http://blogs.msdn.com/b/spike/archive/2010/12/15/running-a-database-mirror-setup-with-the-sqlbrowser-service-off-may-produce-unexpected-results.aspx
...but the SQL Browser Service is running and I can't figure out why the name won't resolve when connecting to the mirror.
I'm assuming there is a service that must be running to enable NetBIOS name resolution that is not running, because this is what I see in WireShark consistently without a response from the Mirror:
Source Destination Protocol Length Info
10.200.3.111 10.200.5.255 NBNS 92 Name query NB SQL-02-SVR-<00>
Question 1: What could be causing the problem? ;-)
Question 2: I really don't want to enable NetBIOS (for security reasons) and I'm using IP addresses (no FQDNs) in the mirror configuration and in the connection string. Given the caching behavior of the mirror partner when connecting to the Principal, is there a way to force TCP/IP to be used so the value that is cached is the IP address and not the name? Do I need to run the SQL Server Browser/Computer Browser services?
The configuration:
App Is Delphi XE2 using SDAC 6.5.9 (I don't think this is relevant to the component I'm using because it works in other installations with mirroring and has no issues)
SQL Server 2012 Enterprise installed as a default instance on Principal, Mirror and Witness in a non-domain configuration using certificate authentication.
Windows Server 2008 R2 SP1 64-bit on all machines
Firewalls disabled on Principal, Mirror and Client (where app is running)
TCP/IP and Named Pipes enabled on Principal and Mirror
SQL Server Browser service running on Mirror
Computer Browser service running on Mirror
Mirroring is configured for automatic failover with a witness and works properly (I can fail back and forth between mirror and principal without issue)
SQL Native Client 2012 installed on Client machine
Same app login (with same SID and user rights) exists on both Principal and Mirror
Correct server, failover partner, database name, user name and password verified in my app log
In connection string, principal server is 'tcp:10.200.3.15,1433' and failover partner is 'tcp:10.200.3.16,1433' using the SQL Native client
I can ping both servers from the Client machine
NetBIOS over TCP/IP has been enabled in the adapter under the WINS tab (on the Mirror and Client machines)
I've been able to get the application working with mirroring on several other installations, but this one is baffling me.
I found the problem, which was that the customer had the Principal and Mirror in one VLAN and the Client(s) in another. Although the IP addressing scheme was the same, the policy for communication between the VLANs prevented broadcast messages, which is why the NetBIOS query was failing on the client. A WINS or DNS server will be implemented to resolve this issue.
However, I am still interested in an answer to my Question #2, above.