I am running into an issue trying to enable hyper-v replication on Windows Server 2016. I have tried via HTTP and HTTPS (AD signed certificates) and neither works. The interesting thing is, I already have another VM replicating between the two servers so I know its possible.
The current error is:
[Main Instruction]
Enabling replication failed.
[Expanded Information]
Hyper-V failed to enable replication for virtual machine 'VM2': The operation timed out (0x00002EE2). (Virtual machine ID 134E9F3F-XXXX-XXXX-XXXX-1AC608804212)
However this doesn't make sense as I can ping the server (ping works from both sides) and I can connect to port 80 and 443 from each side (VS1 and VS2) - note they are on different subnets however that shouldn't matter. Also both servers are part of the domain so authentication shouldn't be an issue (I am logged in as a domain admin and have a valid kerberos ticket) and there is nothing in any of the event logs that gives me any sort of clue as to what is wrong.
Anyone have any ideas of what might be wrong?
just had the same problem. This link helped me a lot:
https://social.technet.microsoft.com/wiki/contents/articles/24258.hyper-v-troubleshooting-error-0x00002ee2-while-enabling-replication.aspx
as described it could be a problem with your routing. I was able to solve it by enabling BypassProxyServer
the powershell command should look something like this (Keep in mind that this configuration is powershell only):
Set-VMReplication -vmname "name" -AuthenticationType Kerberos -ReplicaServerName "servername" -ReplicaServerPort "Port" -BypassProxyServer $true
Related
This server worked not too long ago (I don't have a specific date). We use it for testing and had successfully deployed a few applications. Upon returning to the project I could no longer access the applications chrome saying the site cannot be reached when I netstat -an | grep 'LISTEN'.
I can see the unsecured port but the SSL port is missing in action. I asked the networking team if the ports were being blocked and they said no. I tried to force the application to use the secure port by disabling the unsecured port, restarting the managed server but the it fails to start with this configuration.
Any thoughts? SSL is not really my area of expertise (this is my first exposure). When googling the title I didn't see any results that matched the problem I am having, or at least I did not realize they did...
The server will restart if I enable the unsecured port.
# Gerardo Arroyo, yes this seems to be the issue. I assumed that this server used the same certs as other servers in the test system but it seems I was wrong. I will request a new cert from the networking team. Thank you
I am hoping someone can help me out with a frustrating configuration problem I'm having with IBM FileNet Content Manager 5.2.1 (aka P8 5.2.1).
We have an existing system setup that uses Microsoft Active Directory as our LDAP directory service for P8 and that has worked fine to date. That said, we are now wanting our .NET apps to talk to P8 (via the Content Platform Engine .NET API) using WCF instead of legacy (and now deprecated) WSE but we have run into a problem. WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well (in the process, changing LDAP to use port 636 instead of 389).
Following both Microsoft's and IBM's docs, I first enabled LDAP over SSL on Active Directory and tested accordingly. Using Microsoft's LDAP utility, ldp.exe, I can successfully connect and bind to Active Directory on port 636 over SSL.
The next step however is where I hit a wall - Enabling SSL for Content Platform Engine. I followed all the steps involving adding the Active Directory Server's CA certificate to the CPE's application server keystore - no problem. The next step in the configuration instructions however asks you to start the Administration Console for CPE (ACCE) and reconfigure the directory configuration properties - telling it to use SSL on port 636 and... KABOOM! When I attempt to save the configuration, the save fails, stating
An unexpected exception occurred. Message was: Failed connecting to ldap://ad1.domain.com:636
Unfortunately, I can't find any additional info as to why it failed to connect - I assumed it was due to something minor, such as a port conflict. To test that theory, I installed Microsoft's LDAP test utility on the CPE server and attempted to connect to the Active Directory Server over SSL on port 636. Much to my surprise, that worked just fine - grrrr...
I am now at something of a loss as to what to look at next. Anybody out there with experience configuring CPE to use SSL in an Active Directory environment?
Thanks in advance for any-and-all assistance.
WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well
This is not true. FileNet can work with non-secure LDAP, while at the same time working with WCF.
Now, if you would like to solve why FileNet will not connect to a secure LDAP, then you should start with your WebSphere
Check WebSphere's Keystores to ensure that the AD's key is contained. Follow #M.Tamboli's advice and restart WebSphere.
Also make sure that you check WebSphere's SystemOut.log logs, as you may find more info in there.
I'm not sure if it is necessary, but you may also want to add/change the LDAP config that is setup within WebSphere itself.
I've got an abuse message from Spamhouse with following:
The host at this IP address is currently being used to distribute malware.
Malware distribution located here:
http://xxx.xx.xx.xxx:8080/get/get.php
Where http://xxx.xx.xx.xxx is our domain.
We've found that any request to port 8080 returns Malware.
We use Apache 2 on server. But there are now any setting on port 8080.
Just looing for ideas how to fix that bug?
At the moment we closed port 8080. But there are still some malware inside.
Will appreciate for any suggestions.
Pull that server offline now.
Deploy new server.
Ensure all relevant OS and application updates are applied.
Double check security configuration.
Restore your data from a verified backup.
Then investigate the original server logs/etc. for clues as to how you were infected in the first place.
We have a Win Server 2008 box being hosted (dedicated) for us.
I need to connect to one of it's DB's from a server in our LAN.
What started out as a "sure, I'll just throw that together for you real quick" project has turned into a week-long hair-pulling pile of WTF :)
I am able to RDP into that server without fail or issue.
When I tried to connect to the DB, I got a generic "could not connect" error, so I went hunting.
Telnet attemtps and pings time out.
Since then, we have tried endless variations of firewall settings (including wide open), and still ... no go.
In addition to our firewall, the hosting provider also has a firewall layer.
We turned on all logging, and we don't even see any connection attempts at our FW.
We then had the hosting provider turn on all logging, and they don't see any connection attempts either!
Hrmmmph
I'm at a complete loss.
Any suggestions?
BTW, while I'm comfortable enough with all this to explore and make changes, my experience with firewalls and stuff is fairly limited, so don't hesitate to dumb it down ;)
It is hard to give just one answer to this question, because the interim results of the problem analysis lead to different steps that you need to do next. It will more likely be a step by step help with tracing down the problem.
Do not trust any firewall setting (esp. not any that someone else did, and again esp. not if you don't know him), unless you tested it. Firewall settings are tricky and even experienced professionals get them wrong now and then.
In the guide below, I will write <win2008server> in commands where you have to put the name or IP of the windows 2008 server to which you want to connect. On the other side, I will use the expression "office PC" when I mean your workstation PC in the office from where you are trying to connect to the win2008server.
STEP 1: Checking the Endpoints
1.) Can you telnet to the RDP port?
On your office PC, try this on a command prompt:
telnet <win2008server> 3389
This is to make sure that DNS name resulution works for telnet, as well as network hardware and routing. It should, because you can use RDP to establish this connection. However, anything can get in between, like the telnet command being in any way configured nonstandard or being replaced for whatever reason on a company pc (sysadmins have strange ideas at times...).
2.) Can you telnet locally on the win2008server to the database?
When logged in using RDP on the win2008server, open a command prompt on the server and issue the command
telnet <win2008server> <database port>
That means you are trying to connect from the server to itself. This is to make sure the database port is open on the server.
STEP 2: Checking the Firewalls of the Endpoints
If for 1.) and 2.), your answer is yes it works, you have to test if either the remote side can not be reached or your location can not connect to the internet on the port you are testing (database port). You do this by replacing the respective other side with any other host on the internet for which you know it's reachable or can reach other servers. Typically, you google for a port checker ;)
3.) Check if the win2008server can be reached from another location than yours:
3.1.) Check if the RDP port of the win2008server can be reached from a third party location:
Google for port checker and take the first result (e.g. http://www.yougetsignal.com/tools/open-ports/ ). Type in the name or IP address of the win2008server and the RDP port, usually 3389 . Click on "check" and wait for the success or the timeout.
3.2.) Check if the database port of the win2008server can be reached from a third party location:
Do the same as in 3.1.), just with the database port instead of the RDP port.
4.) Check if you can connect to an outside server on the database port:
For this to work, you need to know a server or create one, which is somewhere outside on the internet, and which listens on the database port. You typically do this by keeping your private PC at home run and accessible through RDP or SSH, and there you open a server and configure your private internet router to forward the connection correctly.
Another way to do this test is webspace with SSH access. Many webspace providers nowadays allow for an SSH login (usually any webspace at $4/month and above).
Let's assume you have SSH access to any such third party place. You can use nc (netcat) there to open a server socket on the database port with this command:
nc -l <database port>
If it's your private PC at home, you usually have to also configure your private router and set up a dynamic DNS name for your internet access for the whole story to work out. You do not have this extra work with a webspace based SSH login. However, there you can not test ports below 1024 because you do not have the privileges. Good luck with this ;)
After you got this, try connecting to the port that you opened:
4.1.) From your office PC with
telnet <third party location> <database port>
4.2.) If 4.1.) does not work, also try with the port checker, because you might have gotten something wrong with setting up the server. Look at 3.) for this, and use the <third party location> and <database port> with the port checker (fourth party check).
STEP 3: Blaming ;)
At least one of the things should have failed by now and you can start calling people and letting them know about your tests and the results. You should be able to combine the results logically, but never start with that. Think about how to convey the information. Start out with your findings and then let them have a moment for their own conclusion. It can be difficult to tell someone in another company or department that their firewall isn't configured correctly. They might deny this even in the presence of proof. Be patient. Explain your findings again. Hint at the conclusion. This can be the trickiest part of the whole problem solution.
I have to say that today I had the same problem.
My solution was just to edit secpol.msc and disable all the FW profiles; then, run services.msc and also disable Windows Firewall service.
After this server was pingable for me.
RabbitMQ starts up just fine, but the shovel plugin status is listed as "starting".
I'm using the following rabbitmq.config:
Each broker is running on a separate AWS instance. The remote server is windows 2008 server, the local server is Amazon Linux.
[{rabbitmq_shovel,
[{shovels,
[{scrape_request_shovel,
[{sources, [{broker,"amqp://test_user:test_password#localhost"}]},
{destinations, [{broker, "amqp://test_user:test_password#ec2-###-##-###-###.compute-1.amazonaws.com"}]},
{queue, <<"scp_request">>},
{ack_mode, on_confirm},
{publish_properties, [{delivery_mode, 2}]},
{publish_fields, [{exchange, <<"">>},
{routing_key, <<"scp_request">>}]},
{reconnect_delay, 5}
]}
]
}]
}].
Running the following command:
sudo rabbitmqctl eval 'rabbit_shovel_status:status().'
returns:
[{scrape_request_shovel,starting,{{2012,7,11},{23,38,47}}}]
According to This question, this can result if the users haven't been set up correctly on the two brokers. However, I've double-checked that I've set up the users correctly via rabbitmqctl user_add on both machines -- have even tried it with a different set of users, to be sure.
I also ran an nmap scan of port 5672 on the remote host to verify is was up and running on that port.
UPDATE Problem isn't solved but this does appear to be a result of connection problems with the remote server. I changed "reconnect_delay" to 0 in my config file, to avoid having shovel infinitely re-try the connection. Highly recommend others with this problem do this as well, as it allows you to get error messages out of rabbit_shovel_status. In my case I got the following error:
[{scrape_request_shovel,
{terminated,
{{badmatch,{error,access_refused}},
[{rabbit_shovel_worker,make_conn_and_chan,1},
{rabbit_shovel_worker,handle_cast,2},
{gen_server2,handle_msg,2},
{proc_lib,init_p_do_apply,3}]}},
{{2012,7,12},{0,4,37}}}]
Answering my own question here, in case others encounter this issue. This error (and also a timeout error if you get it, {{badmatch,{error,etimedout}}, ), is almost certainly a communications problem between the two machines, most likely due to port access / firewall settings.
There were a couple of dumb things I was doing here:
1) Was using the wrong DNS for my remote EC2 instance (D'oh! really dumb -- can't tell you how long I spent banging my head against the wall on this one...). Remember that stopping and starting your instance generates a new DNS, if you don't have an elastic IP associated with the instance.
2) My remote instance is a windows server, and I realized you have to open up port 5672 both in windows firewall and in EC2 security groups -- there are two overlapping levels of access controls here, and opening up the port in the EC2 management console isn't sufficient if your machine is windows server on EC2, as you also have to configure the windows server firewall.