I have 2 servers running Hyper-V. Both servers are off domain and part of the WORKGROUP.
I have setup one of the servers to act as a Hyper-V Replica making use of self-signed certificates. I followed the below guide:
Setup 2 Hyper-V 2016 Servers, enable Hyper-V Replica with self-created certificates and connect to Server Manager on Windows
For a few months now, the replication has been working successfully without any issues. Then yesterday, we started receiving Critical replication errors. see image below:
Hyper-V received a digital certificate that is not valid from the Replica server. The specified cert is self signed (0x80092007)
See Screenshot Error
I have tried repeating the process of creating a new set of certificates, tried restarting both servers, but still no luck of resolving this issue. Strange that it just recently started failing, could this be due to some windows update or Hyper-V update relating to compatibility with self-signed certificates?
Can anyone advise how to resolve this?
Thanks & Regards
Rogan
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\FailoverReplication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
google DisableCertRevocationCheck
We identified the problem was due to a third party software causing a conflict on port 443. Removing this application resulted in the cert working correctly again and no more error.
Related
I'm trying to connect my MAAS version: 2.4.2 to my VMWare Workstation 15.0 so that it will retrieve the machines from VMWare Workstation. I have read earlier questions and answers and saw that the Workstation machines need to be in the 'Shared Folder' so I did that. I also enabled sharing in VMWare Workstation. I checked my firewall and network connection. I am able to telnet to my Workstation machine on port 443 and I get a connection, but when I try to add the "chassis" in MAAS it doesn't give me any response. When I try to edit the power configuration of one of the existing machines and add my credentials it gives me an SSL error:
Can somebody point me in the right direction?
I found the answer. I asked for a solution on the MAAS forums and you can try two things:
Try to import the SSL certificate yourself.
Add 'https+unverified' to the field VMWare API Protocol (optional).
The second solution fixed the problem for me and I can now power on/off the machines from MAAS. Super!
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 an on-premises network and an Azure virtual network that are connected together via a gateway.
With this setup, all machines (on-premises and Azure) are joined to the domain which allows me remote access to the administrative shares as well as remote Powershell sessions on each machine in the Azure virtual network from machines in my office. For example, I can simply open up Windows Explorer and type in the address bar \\machinename\c$ or I can open a remote Powershell session by using the command $Session = New-PSSession -ComputerName machinename.
This works perfectly for one of my Azure subscriptions, but on another Azure subscription that appears to be configured identically, the remote Powershell command is failing with error:
New-PSSession : [machinename] Connecting to remote server machinename failed with the following error message : WinRM cannot process the request. The following error occurred while
using Kerberos authentication: Cannot find the computer machinename. Verify that the computer exists on the network and that the name provided is spelled correctly. For more information,
see the about_Remote_Troubleshooting Help topic.
When I look in DNS on the Azure domain controller, the machine that I am trying to connect to exists. When I look in DNS on-premises, the machine is missing. What it looks like to me is a replication problem between the two domain controllers.
The first thing that is likely to be suggested is to start looking at WinRM configurations on the client machine. To be clear, the same machine is able to connect successfully to machines in a virtual network in a different Azure subscription so it is very unlikely that anything on the client machine needs to be changed. Nevertheless, I Googled the Kerberos error with remote Powershell and have checked that the TrustedHosts setting on the client is set to *.
Interestingly enough, I can successfully open a remote Powershell session from a machine in the Azure subscription to a machine in my office, I just can't go the other direction....from Azure to my office. This would seem to indicate maybe a one-way trust instead of two-way, but I am not sure how to verify this.
I ran the tool and it is reporting that everything is working with regard to replication.
So I guess what I am wondering is if this is truly a replication issue or if someone can give me an idea of what the problem might really be.
Edit 1
Now it looks like the domain controller in the Azure network is replicating just fine but any other VM that I add to the Azure network is not replicating. Based on this I will guess that the replication is working, but it would seem it only works for the domain controller and not any other machine. I have no idea what that means.
Based on the error message, it seems that the DNS records on Azure domain controller are not replicated to the on-premises domain controller.
To verify this, you can run the command below on the on-premises machine, and use the IP address as the value of parameter -ComputerName instead of the machine name. The PowerShell session should be established successfully if this is a DNS issue.
New-PSSession -ComputerName IP address of server on Azure
Also, you can run the following commands on the domain controllers to check the replication status.
repadmin /kcc
repadmin /replisummlry
If the output of commands are successfully, you can run the following command to replicate manually, and check the DNS again.
repadmin /syncall
Finally, to check the trust relationship, you can refer to the following link for step-by-step guide.
https://technet.microsoft.com/en-us/library/cc753821(v=ws.11).aspx
Update
Based on the new information you provided, I would recommend to check the type of DNS zone on the Azure DNS server. Please make sure the type is Primary zone, and store the zone in Active Directory.
You can check this by using the DNS Manager.
I have three windows 2008 R2 servers; DEV, UAT and Live. I am deploying web apps between these servers, including IIS setup and config and database backup and restore via a PowerShell script. I use a powershell remote session.
I would like to prevent any machine, other than my deployment machine, from creating a powershell remote session on the host, even if the user is authenticated. Is this possible?
I have looked extensively through the PSRemoting documentation and can't find anything helpful.
Thanks in advance
Read the below link to better understand what needs to be done but I think you need to set the trusted host on the remote servers.
http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2008/02/23/remotely-managing-your-server-core-using-winrm-and-winrs.aspx
This is an excerp from the blog.
On the Windows server Core box
Run the following commands on the console of the Server Core box to lower security:
WinRM set winrm/config/service/auth #{Basic="true"}
WinRM set winrm/config/client #{TrustedHosts="<local>"}
WinRM set winrm/config/client #{TrustedHosts="RemoteHost"}
Where RemoteHost is the host you want to be able to connect to the server.
You can also use certificate-based authentication.
http://blogs.msdn.com/b/wmi/archive/2009/03/23/how-to-use-wsman-config-provider-for-certificate-authentication.aspx
If you only want your computer to be able to connect, install the certificate on your computer and don't give it to anyone else.