Tag Archives: powerCLI

Cohesity Basics – Excluding VMs Using Tags – Real World Example

Posted on by

I’ve written before about using VM tags with Cohesity to exclude VMs from a backup. I wanted to write up a quick article using a real world example in the test lab. In this instance, we had someone deploying 200 VMs over a weekend to test a vendor’s storage array with a particular workload. The problem was that I had Cohesity set to automatically protect any new VMs that are deployed in the lab. This wasn’t a problem from a scalability perspective. Rather, the problem was that we were backing up a bunch of test data that didn’t dedupe well and didn’t need to be protected by what are ultimately finite resources.

As I pointed out in the other article, creating tags for VMs and using them as a way to exclude workloads from Cohesity is not a new concept, and is fairly easy to do. You can also apply the tags in bulk using the vSphere Web Client if you need to. But a quicker way to do it (and something that can be done post-deployment) is to use PowerCLI to search for VMs with a particular naming convention and apply the tags to those.

Firstly, you’ll need to log in to your vCenter.

PowerCLI C:\> Connect-VIServer vCenter

In this example, the test VMs are deployed with the prefix “PSV”, so this makes it easy enough to search for them.

PowerCLI C:\> get-vm | where {$_.name -like "PSV*"} | New-TagAssignment -Tag "COH-NoBackup"

This assumes that the tag already exists on the vCenter side of things, and you have sufficient permissions to apply tags to VMs. You can check your work with the following command.

PowerCLI C:\> get-vm | where {$_.name -like "PSV*"} | Get-TagAssignment

One thing to note. If you’ve updated the tags of a bunch of VMs in your vCenter environment, you may notice that the objects aren’t immediately excluded from the Protection Job on the Cohesity side of things. The reason for this is that, by default, Cohesity only refreshes vCenter source data every 4 hours. One way to force the update is to manually refresh the source vCenter in Cohesity. To do this, go to Protection -> Sources. Click on the ellipsis on the right-hand side of your vCenter source you’d like to refresh, and select Refresh.

You’ll then see that the tagged VMs are excluded in the Protection Job. Hat tip to my colleague Mike for his help with PowerCLI. And hat tip to my other colleague Mike for causing the problem in the first place.

VMware – Joining an ESXi 5.5 Host to Active Directory with PowerCLI

Posted on by

I spoke about restarting some ESXi services when joining a domain in this post. Here’s how you might want to do it with PowerCLI. Firstly, you may need to modify the execution policy for PowerCLI. It’s worth checking out the Microsoft URL in the test here, as it’s very useful background on what you’re actually doing by setting this policy. Also, big thanks to my colleague Michael for coming up with the syntax here, he’s really the brains behind the operation.

 

PowerCLI C:\Windows\system32> Set-ExecutionPolicy RemoteSigned

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust.
Changing the execution policy might expose you to the security risks described
in the about_Execution_Policies help topic at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the
execution policy?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):

 

Then when you connect to your vCenter host, you’ll get warned about the certificate. This assumes that you’re not using the right certificates in your environment (why are you like this?).

 

PowerCLI C:\Windows\system32> Connect-VIServer 172.16.200.200
WARNING: There were one or more problems with the server certificate for the
server 172.16.200.200:443:

* The X509 chain could not be built up to the root certificate.

* The certificate's CN name does not match the passed value.

Certificate: [Subject]
  OID.1.2.840.113549.1.9.2="1382062929,d8ba9993,564d7761726520496e632e",
CN=localhost.localdom, E=ssl-certificates@vmware.com, OU=VMware vCenter Server
Certificate, O="VMware, Inc.", L=Palo Alto, S=California, C=US

[Issuer]
  E=ssl-certificates@vmware.com, CN=localhost.localdom CA af1bb298, O="VMware,
Inc.", L=Palo Alto, S=California, C=US

[Serial Number]
  01

[Not Before]
  17/10/2013 12:22:09 PM

[Not After]
  16/10/2023 12:22:10 PM

[Thumbprint]
  4883C2F3DCD6E6F8693200E41BDE2A41A88C3930

The server certificate is not valid.

WARNING: THE DEFAULT BEHAVIOR UPON INVALID SERVER CERTIFICATE WILL CHANGE IN A
FUTURE RELEASE. To ensure scripts are not affected by the change, use
Set-PowerCLIConfiguration to set a value for the InvalidCertificateAction
option.

Name                           Port  User
----                           ----  ----
172.16.200.200                 443   root

 

You can then get down to it. Firstly, you can join the domain with this command.

 

#To Join the domain: 
#get cred for joining the domain
$cred=get-credential

get-vmhost | Get-VMHostAuthentication | Set-VMHostAuthentication -JoinDomain -Domain "network.internal" -Credential $cred

 

Once you’ve done that, you might need to restart those services I spoke about at the end of a previous post.

 

#To restart these pesky services:

Get-VMHost | Get-VMHostService | ?{"lsassd","lwiod","netlogond" -contains $_.Key} | Restart-VMHostService

 

Once you’ve done that, you can check if it’s all working with this command.

 

#check to see if you have any auth issues

get-vmhost | Get-VMHostAuthentication

 

And you should be good to go.