new tag assignment

Creating tags and assigning tags to the list of VMs using PowerCLI (2149731)

This article helps to create new tag and assign tags to the list of VMs using PowerCLI.

This script help you to create New Tags along with the new Tag Category if not existing.

Script can assign the tags to the all the VMs present in vSphere Environment.

$VMNames = Get-VM

$VMNames.Name | Out-File c:\scripts\vmnames.txt

$FileContent = Get-Content c:\scripts\vmnames.txt

$uTagName = Read-Host "Enter VM Tag Name"

#Assign Tag to VM

$GetVMTag = Get-Tag -Name $uTagName -ErrorAction Stop

Write-Host "TagName found"

foreach($VMinFile in $FileContent)

Get-VM $VMinFile | New-TagAssignment -Tag $GetVMTag

Write-Host "Tag Assignment completed"

Write-Host "Tag name you entered not found, let's create one"

$YesOrNo = Read-Host "Please confirm, if you would like to proceed further (Y/N)"

if(($YesOrNo -eq 'y') -or ($YesOrNo -eq 'Y'))

$uTagCatName = Read-Host "Enter Tag Categaory under which you would like to create new Tag"

$GetVMTagCat = Get-TagCategory -Name $uTagCatName -ErrorAction Stop

Write-Host "TagCategory found"

$uNewTagName = Read-Host "Enter New Tag name"

$uNewTagDes = Read-Host "Enter Tag Description"

New-Tag -Name $uNewTagName -Category $GetVMTagCat -Description $uNewTagDes

Write-Host "TagCategory you entered not found, let's create one"

$uNewTagCatName = Read-Host "Enter New TagCategory name"

$uNewTagCatDes = Read-Host "Enter TagCategory Description"

New-TagCategory -Name $uNewTagCatName -Description $uNewTagCatDes

Write-Host "Now, let's create a new Tag under TagCategory:" $uNewTagCatName

New-Tag -Name $uNewTagName -Category $uNewTagCatName -Description $uNewTagDes

$GetVMTag = Get-Tag -Name $uNewTagName -ErrorAction Stop

• VMware vSphere Web Client
• VMware vSphere Client
• VMware vSphere

Resolving the mysterious and unknown issues with the PowerCLI Tag cmdlets!

Published by bryan van eeden on may 14, 2020 may 14, 2020, introduction to vsphere tags.

VMware vSphere Tags is a way to attach metadata to VMware vCenter inventory objects to make it easier to find and recognize these objects. If you, like me, know about this functionality within vSphere, you know how useful this can be. In previous versions of vSphere, VMware had something (it’s still available) that is called vSphere Custom Attributes . Custom attributes seemed to be troublesome to manage and from my own experience it wasn’t practical to use as a system administrator on a larger scale.

You can add a tag or label on almost all vSphere inventory objects. These tags can also be assigned to categories, which can group tags together under one group. Below a quick summary that shows the vSphere objects that can be tagged (You can also find this within PowerCLI; execute Get-Help New-TagCategory -Detailed ):

• Datastore Cluster
• Distributed PortGroup
• Distributed Switch
• Resource Pool
• Virtual Portgroup
• Virtual Machine
• Libary Item
• Content Library

You should know that if you choose all objects when you initially create the category, this cannot be changed later on. Within each tag category you can choose to have a cardinality of one or multiple. This means that within this tag category you can either have a maximum of one assigned tag on an object, or multiple assigned tags from the same category. You should be aware of this because if you for example want to use this feature for customer identification, you do not want multiple customer tags attached on the same vSphere object, you’d want to have those mutually exclusive.

Now let’s go to the nitty-gritty details! If you follow the below PowerCLI code examples you will create a vSphere Tag Category called “Customer” and a Tag called “CustomerA”. The cardinality will be single, since you don’t want to have multiple customer names on a vSphere object, and only vSphere VM objects are allowed to be tagged.

So once you’ve done this, you can use it to assign tags to virtual machines in the vSphere inventory. So let’s say we want to assign the recently created tag to a list of virtual machines that are currently in the ResourcePool called “CustomerA”.

Once the vSphere objects are tagged you can sort through them with ease with PowerCLI, by for example the following couple of commands:

And so on and so forth. If you are using Enhanced/Embedded Linked Mode in your vCenter configuration you should be aware that you need to provide the "-Server" parameter to the New-TagAssignment command. Tags get replicated between vCenter’s in a ELM configuration, but I’ve had issues with tag assignments while not using the "-Server" because each vCenter has the tag present. Which means, if you have 3 vCenters in the ELM configuration and you are connected to all vCenters during execution of the script, all tags are present 3 times. So providing the "-Server" parameter ensures that the correct tag on the correct vCenter is being used.

So far so good right? Well yes it is. The Tag cmdlets are very easy to use and have improved in performance significantly since PowerCLI 11.3 . But what when you are receiving weird errors during execution of the Tag cmdlets? Well the weird issue we encountered resulted in the following behaviour:

These errors prevented us from using any of the below “Tag” cmdlets:

For the sake of documentation below are some details from the environment:

• VMware vCenter 6.5 U1e build 7515524 was used in the beginning when this issue started occuring.
• VMware vCenter 6.7 U2c build 14070654 was used once we upgraded the VMware vCenter servers.
• PowerCLI versions 6.5.0 R1 (which worked), PowerCLI 10.0.0, 10.1.1.8827524 and multiple version 11’s. The latest version I’ve been using is: 11.5.14912921.
• vCenter PSC versions 6.5 U1e build 7515524 and 6.7 U2c build 14070654 have been used.
• We are using an external Platform Services Controller (PSC) with three attached VMware vCenter servers in Enhanced Linked Mode . All vCenter servers are having the same issue.
• The vCenter Servers have been upgraded since version 5 (Windows) to this VCSA version during its lifetime.

And so to be clear to everybody that is reading this blogpost. All services either external or internal facing (between vCenter Server and PSC) are working without issues. The only issue we are having is the one I described above.

Troubleshooting the issue

Looking at the error messages that Powershell provides, it seems that we cannot create a SSO session with the vCenter server. Let’s test that:

In the above code snippet we’ve succesfully connected to the vCenter server on port 443 and checked the active connections. That seems to work. Port 443 is also the only requirement to connect to a vCenter Server. Running a command also works just fine. So we can connect to the vCenter server, that isn’t the problem. Next up, are the PowerCLI versions interoperable with the vCenter versions?:

Looking at the above interoperability matrix it seems that we are also good to go on this part, everything is supported. Next up I checked a couple of other things among the following:

• vCenter Server firewall rules – not present
• Jumphost firewall rules – not present
• All vCenter Server 6.7 required ports were accessible.

VMware Support case

At this point I actually raised a support ticket with VMware. This ticket actually lasted for almost 6 months after which it got closed without a solution. I discussed the messages that regard port “7444” with VMware in length. But the conclusion the VMware engineer made was that it was due to the fact that we were running a mismatching version between the PSC and vCenter Server (This was true in the beginning). He also mentioned that we shouldn’t be encountering this error because port TCP/7444 wasn’t being used anymore on the front-end. Starting from vCenter Server 6 the SSO Lookup Service moved to port 443 instead of 7444 through the HTTP Reverse Proxy service. Which means it’s only used for internal communications. On version 6.5 it is being used for backwards compatibility since the PSC can support vCenter Server 5.5. The last recommendation I got from VMware was to re-deploy a new PSC and repoint our vCenter Servers. Since this is quite rigorous, I decided I wasn’t going to do this.

Troubleshooting session #2

At this point we moved our focus from this case since on some stations we were able to use the Tag cmdlets, and on other stations we couldn’t. Since most scripting stations we’re able to assign Tags on virtual machines we decided to let it rest. Until I noticed this on a new scripting server I build for our environment. At this point I re-opened my own troubleshooting sessions and decided something else.

Since the error messages are mostly regarding a SSO session on port 7444, I decided to use Wireshark to try and see what the Powershell session was actually doing. This resulted in the following:

In the above snippet we can obviously see that something isn’t right. It actually tries to connect on port 7444 for the Lookup Service , which it shouldn’t since it’s not used anymore . Just to double check myself I tried this query against a working good vCenter Server and it’s completely empty. So we now know that this should normally not happen. This also means that if this is a behaviour you can detect for your vCenter Server, you should continue reading!

At this point it was clear to me that our vCenter Server environment isn’t completely without issues anymore. I decided to try and open up port 7444 and to reconnect and try the Tag cmdlets once more. And guess what, it started to work, sort off. I was one step further, at this point the Powershell window threw the following error at me:

Come again? We have a fully working signed certificate, which isn’t expired and it’s signed by an external/public CA. After doublechecking this (with echo | openssl s_client -connect localhost:443 ) I figured maybe it is failing on the certificate that is present on port 7444, since we were able to connect before we opened up port 7444. You can actually browse to the Lookup Service (e.g. https://vc01.vcloudvision.lab:7444/lookupservice/mob) and check what certificate is being used or use echo | openssl s_client -connect localhost:7444 . After doing this I noticed that there was a certificate named “ssoserver”. This certificate is an internal certificate, so why am I getting errors on this?

Well since this vCenter Server environment got upgraded all the way from vCenter Server 5.5 to the current vCenter Server 6.7 it seems that the internal migration for the SSO services (specifically the SSL Trust Anchors) from back in the day (VCSA 6 to VCSA 6.5) didn’t completely go well.

The solution part 1

Now if you have a healthy vCenter Server environment apart from this minor issue, you can do the following to enable your colleagues to be able to use the Tag cmdlets again:

• Open up port TCP/7444 from your jumphost/scripting host to your PSC, or vCenter Server if you are seeing these issues when using the Embedded PSC.
• Use Set-PowerCLIConfiguration -InvalidCertificateAction Ignore to ignore the ssoserver “invalid” certificate that your Lookup Service is using at the moment.

After this you will be able to use and do everything you should be able to do with PowerCLI.

The Solution part 2

But if you also want to fix the real underlying issue, you are going to have to do a couple of things. At first you will have to make sure you are actually experiencing the same issue as above. You can do this by following the below step-by-step guide:

• Are you receiving the same error messages when using PowerCLI Tag cmdlets like I mentioned above? Continue to step 2.
• Are you still using port TCP/7444 (check with Wireshark)? Continue to step 3.
• https://vc01.fqdn:7444/sts/STSService?wsdl or;
• https://vc01.fqdn/sso-adminserver/sdk/vsphere.local (The default SSO admin URL, can also be found with Get-AdvancedSetting -Entity $global:DefaultVIServer -Name 'config.vpxd.sso.admin.uri' | select -ExpandProperty Value ) or with (/usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location --server-name localhost) or;
• https://vc01.fqdn:7444/lookupservice/sdk

And receive anything else than the current correct configured SSL certificate like below:

You will probably have the “ssoserver” certificate showing. If this is true, you can safely assume that the SSL Trust Anchors have not been properly migrated over during the migrations in the past. The last part you need to do to check this is executing the following command on your VCSA:

If you want to do this through the GUI use the following URL and login with “[email protected]”:

In the “filterCriteria” field you need to delete everything so that it displays the following and press “Invoke”:

Both of these ways will list the sslTrust Anchors for all the registered Lookup services on the PSC/vCenter server. You will have to search through the file or through the GUI on the following two Endpoint types:

If any of these two Endpoint types contain the port TCP/7444 in the URI/URL, and the registration is still valid (as in it’s being used, look at the ownerId field), the legacy SSO endpoints are not correctly configured anymore. If they are no longer valid because of outdated or decomissioned external PSC servers, you can clean those entries up with:

Just remember you have some downtime if you clean this up because services get restarted.

So if you don’t have these outdated entries, what do we do now? Well the Lookup Service has to be re-registered. This can be done through a couple of ways. I will try to describe these below:

• Open a case with VMware GSS. They have a script called “lsdoctor-master” which corrects this issue. This is also the safest solution. Tampering the Lookup Service registrations might destroy your vCenter Server. Make sure you have a working backup before you try anything!
• While looking at solutions for my use case I also found this post on Reddit. By coincidence I looked into the comments and found that the user theVelement posted a couple of links for a script he wrote that leverages the ls_update_certs.py script on the vCenter Server and updates the endpoints with the corrent sslTrust Anchors.As far as I can see he made these scripts, which can both be found HERE for bash or HERE for PowerShell. I ran these on my test environment and they seem to work. Remember, this is not anything that is official from VMware so you should use this at your own risk. Using the script is very easy. Just run “–help” to find all arguments and run “-cmle” to test current entries.

So once you have done this you can easily run the script to fix the entries. Just run “-fml” and enter the “[email protected]” credentials, the SHA thumbprint that needs to be fixed and simply press Enter. That would look like something as below:

• You can also do this by hand, which is a lot of work. All of these steps can be found in the following VMware KB . I actually recommend trying the script above in step 2 first, simply because it looks like it works, and it actually uses the same process, but done in a couple of minutes. But like I said before, the script is made by the community and not supported, the KB is official.

So once you’ve fixed the sslTrust Anchors, you should return to doing a couple of checks like earlier in this blogpost:

• Can you now use the Tag cmdlets without any issues (while port TCP/7444) is closed?
• If you run the following command, are there any entries for the “com.vmware.cis.cs.identity.sso” or “com.vmware.cis.cs.identity.admin” with the 7444 port (it should not!).
• Browse to https://vc01.vcloudvision.lab:7444/lookupservice/mob and check what certificate is being used or use echo | openssl s_client -connect localhost:7444 to do the same. If the “ssoserver” certificate is still there it’s not good. It should look something like the certificate below:

So to conclude this blogpost. We started off with a vCenter Server with no real issues except the problems with Tag cmdlets from scripting servers that did not have an open connection to the vCenter Server on the legacy Lookup Service port 7444. During the long troubleshooting period I took for this case it turned out there was an underlying issue with incorrectly migrated sso sslTrust anchors/registrations during previous vCenter Server upgrades.

So the next thing we did was provide a quick and dirty work-around to get you guys going again by allowing the legacy port in the firewall and accepting the internal ssoserver certificate on your PowerShell sessions. To really fix the underlying issue with SSO you can either check out this blogpost and try it out or/and open up a case with VMware. Like I said before tampering with these registrations might destroy your vCenter Server so be careful!

Thank you for reading, stay tuned for future blogposts!

More posts on our blog...

• NSX-T Tier 1 GW not connected to Edge Nodes
• How to fix VMware Cloud Director 10.4.x bug that…
• Refresh NSX-T site information
• How to quickly find NSX-V KB85070 affected ESXi hosts
• How to replace the NSX Manager Local-Manager…
• VMware Cloud Director 10.5.1 database bug causing…

Bryan van Eeden

Bryan is an ambitious and seasoned IT professional with almost a decade of experience in designing, building and operating complex (virtual) IT environments. In his current role he tackles customers, complex issues and design questions on a daily basis. Bryan holds several certifications such as VCIX-DCV, VCAP-DCA, VCAP-DCD, V(T)SP and vSAN and vCloud Specialist badges.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Related Posts

Using the adapter instance in aria operations notifications.

When building a new VMware SDDC it takes some time before you can hand over management duties to an existing team. In the meantime you want to get notified when something breaks using tools which are already in place. In this blog post I will explain how to use the adapter instance in Aria Operations so you can easily filter notifications.

Troubleshooting

How to fix usage meter 4.8 not uploading consumption data.

Introduction The other day we updated our UsageMeter environment to 4.8. We have a couple and all of them including this appliance worked fine after the upgrade. After a couple of days I received a Read more…

VMware Cloud Director 10.5.1 database bug causing strange issues

Introduction The other day we upgraded our VMware Cloud Director (VCD) environment. The upgrade itself did not go so well for us, but I will discuss this in another blogpost. However this blogpost is for Read more…

Privacy Overview

Virtu-Al.Net

Virtually everything is poshable, automating tags and tag category creation and assignment with powercli.

After creating a tag, you can assign that tag to a category. Categories allow you to group related tags together. When you define a category, you can also specify the type of objects to which its tags can be applied to and whether more than one tag in the category can be applied to an object.

For example, if you want to tag your virtual machines by the owner, you can create a category called “Owner” and specify that it applies to virtual machines only and that only a single tag can be applied to a virtual machine at any time. The tags in this category could be Alan, John or Fred etc.

I have had a few people ask me how they can use PowerCLI to work with external systems, CMDBs, databases or even just a CSV file.

One example of this is where a company could have various information about hosts or datastores or virtual machines, like the project that purchased these, a cost code or an owner.  This data is generally stored somewhere else but it would be great to see this information straight in the vSphere Web Client where you manage the objects so that you can instantly contact the owner or work out which project the object is being used for etc.

The below video shows how we can use PowerCLI and this generic script I created to import the data, create the tags and tag categories and assign them to the machines, it uses a csv as input but this could obviously be changed to anything which can be read in PowerShell, like a API, database, application etc etc.

Automating tags and tag categories video

Example script.

This script is the script I created as an example which relates each of the items in the Name column to an object in the inventory then for each of the other column headers it will create a category and then the tags that are under the categories, once this has been done it will apply the tags to the objects in the Name column.

15 thoughts on “ Automating Tags and Tag Category creation and assignment with PowerCLI ”

brilliant as always! I notice that this appears to be a one-time process. For example if I take VM1 and place a tag/category onto it via script, I can’t go back and add VM2 to the same tag, it will just ignore it and not do anything. Is there a way to check for existing tags/categories and use them if exist?

You can avoid the loop using: $UniqueTags = $cmdbinfo | Select -expand $name | Sort-Object -Unique

$CMDBInfo = Import-CSV C:\Temp\cmdbinfo.csv

# Get the header names to use as tag category names $TagCatNames = $cmdbinfo | Get-Member | Where {$_.MemberType -eq “NoteProperty”} | Select -Expand Name

# Create the Tag Category if it doesnt exist Foreach ($Name in ($TagCatNames | Where {$_ -ne “Name”})) { if (-Not (Get-TagCategory $Name -ea SilentlyContinue)) { Write-Host “Creating Tag Category $Name” New-TagCategory -Name $Name -Description “$Name from CMDB” | Out-Null

# Create Tags under the Tag Categories $UniqueTags = $cmdbinfo | Select -expand $name | Get-Unique Foreach ($Tag in $UniqueTags) { if (-Not (Get-Tag $Tag -ea SilentlyContinue)) { Write-Host “..Creating Tag under $Name of $Tag” New-Tag -Name $Tag -Category $name -Description “$Tag from CMDB” | Out-Null } # Assign the Tags to the VMs/Hosts $cmdbinfo | Where {$_.($Name) -eq $Tag} | Foreach { Write-Host “…. Assigning $Tag in Category of $Name to $($_.Name)” $TagAssignment = Get-Tag -Category $Name -name $Tag New-TagAssignment -entity $($_.Name) -Tag $Tagassignment | Out-Null } } } }

Hi Al, I was trying to get infront of the line but hopefully I could. I have been using your script to automate creating Tags to all our VMs. Unfortunately, it doesn’t seem to be creating “ALL” of my tags that are in my CSV file. I am actually not sure if it were creating anything because what I see are basically something close to my naming but it has the right information showing. CSV file layout: Name VMToolsVersion Priority_Level Startup_Sequence Cluster_rule(s) Cluster Operating_System Provisioned_MB In_Use_MB Cylance_Agent_Version Cylance_AQT Cylance_Mem_Protection Server1 T4 Management SUSE Linux Enterprise 11 (64-bit) 725685 328153

VIEWED in WEB CLIENT: Assigned Tag Category Description Prod Cluster Prod from CMDB T4 Priority Level DR Priority Level Windows Server 2008 R2 – x64 OS Server 2008 R2 – 64 Based

It shows information that are not specific to what i have on the CSV. Is it because that there could be same info existing tags ? If so then why did it not create a new tag with same information? Also the other column name which should have been created as tags did not get created. How is that? If so, can you assist on a script to wipe out all tags and recreate all tags that are specifically from the CSV? If you could please assist that would be greatly appreciated.

Thank you so much.

Hi all, i have been asked to tag all our VM in side our three vCenters. i already have compile the csv file with columns heading with Name of the server, Department , Owner , Severity and Application, i am not good in powershell, can you please help me where do i need to make changes in this above script? please help me . Thanks.

For others out there that are trying to use this with a large import, the Get-Unique function only works on sorted lists. So if your “Categories” are not sorted the import will get stuck in a loop

Hi Al. Have you ever come across any issues running the Get-TagCategory cmdlets remotely (in my case via vRO)? I’m running PowerCLI 6.3 Release 1 against vCenter 5.5, and have a script on a remote PS host that is failing at the Get-TagCategory step – with an output of ‘null’. All other cmds (Get-VM etc) work without issue. Cheers, Dan

Pingback: Fun with vSphere Tags | Virtual Chris

This is really great material, my question is if you have the same script to export from the vCenter to the Excel file. The the VC DB can be the master, and it would be nice to export –> update –> and then import again.

Yes, you would need to use PowerCLI to do this.

I am currently in the process of trying to organize a Vsphere/Vcenter such that we can determine via tag which tech in the department is responsible for a server and what SLA it is. We would like to see this information at a glance in the tags of each VM. However there are 350 VM’s so tagging them one at a time is going to be hard to track and time consuming. The VMs are currently organized into a VM Folder structure that looks like this (Production\Cisco\Unify\… the VM contained)

My question is this. How can I get Tags made on VM folders to propagate down to the child folders and objects within that folder. For example I would like all the VMs in all the folders of the primary category “Production” to inherit the tag “Production Level Server” that is already setup on the Folder “Production”.

Thus far this is not happening. If I place VM’s objects in a tagged folder they will inherit the tag but folders underneath will not.

Is there a way to do this?

Pingback: [VMware] news + interesting reads from the blogosphere: 01 Dec. 2014

Pingback: [VMware] news + interesting reads from the blogosphere: 25 Nov. 2014

Is there any possibility to use vSphere tags within vCenter Orchestrator workflows without actually using PowerCLI? If not then are there any plans to make it available from within vCenter Orchestrator? I’m not sure how many people are using them, but in our environment it would make things so much easier.

Hello how to use tags with vCheck (Daily Report)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed .

• VMware Technology Network
• Cloud & SDDC
• VMware PowerCLI Discussions

new-tagassignment value cannot be null

• Subscribe to RSS Feed
• Mark Topic as New
• Mark Topic as Read
• Float this Topic for Current User
• Printer Friendly Page

• Mark as New
• Report Inappropriate Content

• All forum topics
• Previous Topic

Set-TagCategory

This cmdlet modifies the specified tag categories. The cardinality of a tag category can only be changed from "Single" to "Multiple".

VMware.VimAutomation.ViCore.Types.V1.Tagging.TagCategory

Retrieves a tag category named "MyTagCategory" and updates its name and description.

Retrieves a tag category named "MyTagCategory" and updates it by allowing more than one of its tags to be assigned to a specific object at a time, as well as adding "VirtualMachine" to the set of applicable entity types.

Related Commands

Tagassignment, tagcategory, was this page helpful.

PowerCLI Reference

New-tagassignment.

Related Commands

Detailed Description

Return Type

-------------------------- Example 1 --------------------------

Assigns the "MyTag" tag to all virtual machines whose name contains the " MyVM " wildcard pattern.