If you ever run an installer and get the following message “Windows cannot access the specified device, path, or file. You may not have the appropiate permission to access the item” try the below. Note: I am assuming that you already have rights…
1. Copy the file to your local machine
2. Right click on the file and go to Properties.
3. Down at the bottom of the General tab you might see a Security option that says “This file came from another computer and might be blocked to help protect this computer.”
4. Click Unblock.
We use VMware vCenter Configuration Manager at our site to monitor our Windows servers for signs of future problems by searching the Windows Event Logs for a predefined list of events. Every once in a while (especially after a while without alerts) you want to test and make sure that everything is indeed being monitored properly. To do this I needed to inject an event into the Event Log and see if we received an alert in VCM. The question was this: how do I impersonate an existing service? The built in eventcreate.exe will not let you add events for a source that already exists, which is exactly what I want to do… Ah, I love it when people have already coded an application to do something that I need to do and save me from having to write it myself.
Meet eventcreate2.exe: http://code.google.com/p/eventcreate2/
Eventcreate2.exe has one flaw, you cannot specify a remote machine; as opposed to the built in eventcreate.exe which does let you specify remote machines. Other than that it is awesome. Using a command like the below I was able to successfully inject events impersonating an existing service and verify that our alerting was indeed working as advertised.
eventcreate2.exe /L Application /T Warning /SO dmboot /ID 2 /D “This is a test Windows RAID Failure Alert”
I recently ran into an issue after replacing my VDR (now VCDR) Appliance from version 1.2 to 2.0 and ran into a very misleading error that can cause confusion. A week after installing the VCDR Appliance I tried to connect to it using the vSphere Client on my laptop and was greeted with the following error: “Error: The Data Recovery service did not start up. If the problem persists, please restart or redeploy the Data Recovery appliance.”
Restarting the appliance does not change the error message and I was worried it was dead but thankfully after doing some digging in the log files I discovered a very interesting error: “UnixResponder: Respond: Rejecting non-SSL connection from client 10.25.43.72 (socket 40)”.
Turns out the problem was something really quite simple. The reason for this behavior was I had the 1.2 version of the VDR Plugin installed on my laptop. Apparently it can sort of talk to the new version 2.0 appliance but not enough to work. All you need to do is uninstall the old 1.2 version of the VDR plugin via Add and Remove Programs and install the new version 2.0 plugin.