You might have stumbled over this error in the sdrsinjector.log.
I did, when I was troubleshooting why sdrsInjector was running haywire on one of the vSan notes.
While there is a KB for this symptom KB2145247 it doesn’t describe the whole solution.
We added an NFS datastore to all our hosts to redirect logs and scratch and we have more than 128 hosts in that vCenter.
So there is the truth, but we don’t have Storage I/O control enabled.
So I enabled the options:
- Disable Storage I/O statistics collection
- Exclude I/O statistics from SDRS
on those datastores.
Unfortunately I had to do that in all datacenters in all vCenters but that wasn’t too hard.
Just a quick note in case you wonder.
The documentation isn’t very clear about which files you need to pick when you want to deploy vSphere Replication 6.5 from the ISO. You will need to select the following 3 files:
Might be obvious, just wanted to note that down.
Isn’t IT fun?
You use a tool and while it normally works you stumble upon an issue which you cannot explain.
While doing some Robocopy jobs (with Robocopy 2008) I stumbled upon the following error:
Error 2 (0x00000002) Accessing Destination Directory TheSourceDirectory The System cannot find the file specified
Error 3 (0x0000003) Copying File TheSourceDirectory The System cannot find the file specified
Source and Target are accessible by the job, exploerer doesn’t show any issues when copying the data, the directory contains sometime a .DS_Store file (haven’t checked all directories).
Using Robocopy from a 2003 Server.
IT, fun as always.
During an upgrade from vSphere 5.0 to vSphere 5.5 we stumbled upon a problem.
We needed to redo the vCenter Server (which isn’t really a problem) but the old cluster had EVC Penryn enabled.
We created a new vCenter Server, created a new Cluster and tried to join a host to it…
No chance… vCenter was telling us that it couldn’t join the host to the cluster with EVC enabled (as the vms where still running).
Ok, so than disable EVC and join the hosts… no issue.
Now enable EVC again…
No chances… some VMs on some servers where using a higher level of CPU Instructions than the EVC level we wanted to enable supported.
So we created a temporary cluster, moved the 2 esx servers with the offending vms into it, by removing them from the vCenter server first as the vms need to be kept running.
Than we set the EVC mode on the original cluster and started migrating the vms from the temp cluster into the EVC enabled cluster.
We only found 2 VMs which we couldn’t migrate as they where using features which weren’t supported on the EVC enabled cluster, one was a MS SQL server.
So we needed to shut them down, migrate them and power them up again.
Yes this isn’t your typical approach on upgrading a vSphere environment, but in the end it did work.
It could be so easy… but it isn’t.
If you want to backup NetApp cifs shares via the File Server Backup options you need to do several steps:
- Disable NDMP on the NetApp
- Add the NetApp as FileServer to Backup Exec
- Have a Remote Agent for Windows License installed
- Have “Enable selection of user shares” Enabled in “Configuration and Settings -> Backup Exec Settings -> Network and Security”
This should do the trick.
In Backing Up NetApp Filer on Backup Exec 2012 Jonas Palencia also changes the NDMP Port on the Backup Exec server but this shouldn’t be necessary.
During upgrading BackupExec to a newer version I stumbled upon the following error:
Visual C++ 2012 Redistributable didn’t install and did show up a strange error in the BE Installation Log.
Running the package manually gave a far better error message:
The cryptographic operation failed due to a local security option setting
There is no direct solution to this problem (at least when you search for it).
The reason why the install fails is because of wrong configurations of the IE Security settings.
This knowledge base article provided the solution:
Error message when you try to validate a copy of Windows: The cryptographic operation failed due to a local security option setting