Windows Systems Admin Job Summary: System Administration: Responsible for the direct system administrator of several dis … for system support purposes. Installs and maintains system and application software. Provides technical system…
When you enable ODX file transfers, consider the necessary support to make them happen as well as taking baselines.
Learn more about this storage system option, which can speed up data transfers and simplify computing overhead.
Windows Server 2012 R2 included changes that specifically addressed problems traditional dedupe had with virtual desktop infrastructure.
Learn how to fix an application having problems with deduplicated data, as well as when you should turn off dedupe.
Dedupe reduces the amount of storage needed for backups, but its performance and effectiveness can vary.
Security is on the minds of Windows Server admins everywhere, so we’ve compiled the best tips to help keep their enterprises secure.
If you are a hosting provider who is interested in offering DR as a service – you should go over this great post by Gaurav on how Hyper-V Recovery Manager (HRM) helps you build this capability http://blogs.technet.com/b/scvmm/archive/2014/02/18/disaster-recovery-as-a-service-by-hosting-service-providers-using-windows-azure-hyper-v-recovery-manager.aspx
The post provides a high level overview of the capability and also a detailed FAQ on the common set of queries which we have heard from our customers. If you have any further questions, leave a comment in the blog post.
Continuing from where we left off, I have a small lab deployment which consists of a AD, DNS, Proxy server (Forefront TMG 2010 on WS 2008 R2 SP1), primary servers and replica servers. When the primary server is behind the proxy (forward proxy) and when I tried to enable replication using certificate based authentication, I got the following error message: The handle is in the wrong state for the requested operation (0x00002EF3)
That didn’t convey too much, did it? Fortunately I had netmon running in the background and the only set of network traffic which was seen was between the primary server and the proxy. A particular HTTP response caught my eye:
The highlighted text indicated that the proxy was terminating the connection and returning a ‘Bad gateway’ error. Closer look at the TMG error log indicated that the error was encountered during https-inspect state.
After some bing’ing of the errors and the pieces began to emerge. When HTTPS inspection is enabled, the TMG server terminates the connection and establishes a new connection (in our case to the replica server) acting as a trusted man-in-the-middle. This doesn’t work for Hyper-V Replica as we mutually authenticate the primary and replica server endpoints. To work around the situation, I disabled HTTPS inspection in the proxy server
and things worked as expected. The primary server was able to establish the connection and replication was on track.
I was tinkering around with my lab setup which consists of a domain, proxy server, primary and replica servers. There are some gotchas when it comes to Hyper-V Replica and proxy servers and I realized that we did not have any posts around this. So here goes.
If the primary server is behind a proxy server (forward proxy) and if Kerberos based authentication is used to establish a connection between the primary and replica server, you might encounter an error: Hyper-V cannot connect to the specified Replica server due to connection timed out. Verify if a network connection exists to the Replica server or if the proxy settings have been configured appropriately to allow replication traffic.
I have a Forefront TMG 2010 acting as a proxy server and the logs in the proxy server
I also had netmon running in my primary server and the logs didn’t indicate too much other than for the fact that the connection never made it to the replica server – something happened between the primary and replica server which caused the connection to be terminated. The primary server name in this deployment is prb8.hvrlab.com and the proxy server is w2k8r2proxy1.hvrlab.com.
If a successful connection goes through, you will see a spew of messages on netmon
When I had observed the issue the first time when building the product, I had reached out to the Forefront folks @ Microsoft to understand this behavior. I came to understand that the Forefront TMG proxy server terminates any outbound (or upload) connections whose content length (request header) is > 4GB.
Hyper-V Replica set a high content length as we expect to transfer large files (VHDs) and it would save us the effort to re-establish the connection each time. A closer inspection of a POST request shows the content length which is being set by Hyper-V Replica (ahem, ~500GB)
The proxy server returns a what-uh? response in the form of a bad-request
That isn’t superhelpful by any means and the error message unfortunately isn’t too specific either. But now you know the reason for the failure – the proxy server terminates the connection the connection request and it never reaches the replica server.
So how do we work around it – there are two ways (1) Bypass the proxy server (2) Use cert based authentication (another blog for some other day).
The ability to by pass the proxy server is provided only in PowerShell in the ByPassProxyServer parameter of the Enable-VMReplication cmdlet – http://technet.microsoft.com/en-us/library/jj136049.aspx. When the flag is enabled, the request (for lack of better word) bypasses the proxy server. Eg:
Enable-VMReplication -vmname NewVM5 -AuthenticationType Kerberos -ReplicaServerName prb2 -ReplicaServerPort 25000 -BypassProxyServer $true
Start-VMInitialReplication -vmname NewVM5
This is not available in the Hyper-V Manager or Failover Cluster Manager UI. It’s supported only in PowerShell (and WMI). Running the above cmdlets will create the replication request and start the initial replication.