Scheduled backup fails with ANS1909E, ANS1512E rc=1 and ANR2579E rc 1

Problem: Scheduled backup fails with ANS1909E, ANS1512E rc=1 and ANR2579E rc 1

Solution: After a quick google you might find this page instructing you to run the schedule in the foreground. This is great unless the schedule is full of other nodes and you can't run it any time during the day. Instead, I checked the schedule details on the TSM server console;

q sched domainname schedulename f=d

The schedule was referencing an object on the node to be backed up. When I verified the path and filename discovered a typo.

Using the update schedule command I fixed the path;

update sched domainname schedulename objects='"c:\Program Files\Tivoli\TSM\Backup.cmd'"

Note: In order to get quotes around the path you need to enclose the quotes on the front/end with a single quote. ie. singlequote doublequote string doublequote singlequote

Deploy EPOPS agent to all Windows servers using PSEXEC

Problem: VMware doesn't really give you an easy way to deploy out it's EPOPS agents. Not for free anyways.

Solution: Here's a method that worked really well for me. Grab pstools and extract to a folder, c:\temp sounds good. Right-click your CMD prompt and Run As, choose an account that has access to remotely connect to your servers.

Command:
psexec @serverlist.txt -c vRealize-Endpoint-Operations-Management-Agent-x86-64-win-6.2.1-3720494.exe -serverAddress vrops.domain.local -securePort 443 -username admin -password yourpass -serverCertificateThumbprint 03:51:F2:... /verysilent /dir="c:\ep-agent"

The serverlist.txt is a list of your servers you want to deploy to.

Modify this with your environment info. The Cert Thumbprint is copied from the admin web gui. It's pretty long so make sure copy the entire Thumbprint and include it in the command.

Psexec will copy the exe to the c:\windows\system folder on the remote system, execute the command then remove the exe file when it's done. Slick!

Microsoft Cluster Aware Updating failures and fixes

1. Create Prestaged CAU computer object in your Active Directory cluster folder. As an example, use the ClusterName-CAU (ie. Cluster01-CAU). If you don’t do this the CAU wizard will create a randomly named object.

2. Add this new CAU object to the local admins group on all related cluster nodes.

3. Grant cluster object (ie. Cluster01) "full access" to the new CAU object in AD. Open the CAU object, security, add cluster object and check Full Access. Without this access the CAU wizard will fail to complete.

4. Modify the cluster group policy object or local policy on your nodes to grant the cluster object “Force shutdown from a remote system” rights on both nodes. Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Force shutdown from a remote system. Without this option the cluster will update the node but can’t force a restart therefore cluster updating will fail.

Note:
If configuration of the CAU failed… You may see Kerberos errors in the Server Manager console on either node or “failed” objects in the cluster resources list. Check the cluster resources using powershell to verify the prestaged cluster object is properly listed. “get-clusterresource” will list all the cluster resources and states.

If CAU object is listed in a failed state or the incorrect object is listed (perhaps you didn’t properly enter a prestaged computer account) rerun the CAU wizard and remove the role. Re-run the powershell command to verify the objects were properly removed by the wizard. If they weren't removed you can remove them manually with the “remove-clusterresource resourcename” command. If the cluster is in a good state, re-run the wizard and configure it again.

I noticed what might be a glitch in the way the wizard creates the resources. The first time you run the wizard you'll notice one of the resources has a somewhat randomized name slightly resembling the prestaged computer account you created. If you run the wizard, remove the settings, then re-run the wizard to add the settings back a second time they'll be named more closely to your prestaged computer account. Bizarre!

VROPS EP OPS Agent not communicating with server after agent upgrade

Problem: VROPS EP OPS Agent not communicating with server after agent upgrade. No amount of uninstalling/installing seems to fix this. I also cleared the agent data directory and restarted the service with no success. In the agent log you'll see errors "Unable to send autoinventory platform data to server, waiting..."

Solution: I'm making an assumption that your agent config file is accurate and you're not having underlying network issues that would otherwise prevent the agent from communicating to the VROPS node.

On the affected windows guest, open a command prompt (always right click and Run as Administrator!). Change to the ep-agent directory, example c:\ep-agent\bin and type the command "ep-agent setup". This will force the setup to run through your configuration file and reconnect to the server.