Posts

Showing posts from 2020

Using the NSX-T API

I've been writing some PowerShell scripts to automate NSX-T configuration lately, so I figured that I should put together a primer with notes about how to get started!  Firstly, if you're working with the API, you're going to want to be able to reference the official documentation .  There's a lot that can be done via the API, and that guide will tell you what calls to make to do most of it!  If you're like me and haven't spent a lot of time working with APIs before, that document will present a pretty steep learning curve... so I'm writing out my notes here, to make it easier for people to get started! At its most basic, using the API is just sending a web request to the NSX-T manager and then reading the response.  Since this is potentially sensitive information, you're going to have to authenticate with the server though, so you'll need to include a Header with that login information.  If you want to change anything, you're also going to need

Reporting Systems that use KMS

 I was helping a customer resolve an issue with their KMS server recently and we decided that we'd like to get a look at which systems were actually using it, instead of just looking at the total number of systems as displayed by slmgr /dlv.  I couldn't find any slmgr switches that looked like they'd generate a report with this data, but my customer pointed out that we could find it in the event logs (under the Key Management Service grouping), but that it'd be a pain to go through all of the events and pull out the client names.  Well, you can probably guess where this is going - I put together a quick script to do exactly that! This is a really quick and dirty script; I built it to run on the KMS server and generate a table with the client ID in one column and a list of client computer names in the other.  Why is it a list of client computer names?  Well, this particular customer is running a VDI environment and there can be a bit of a problem with KMS and Instant Clo

Problem while Connecting Horizon 7.12 to vCenter

I was setting up a quick Horizon 7.12 PoC environment and ran into a bit of trouble getting Horizon to talk to vCenter.  Every time I tried to add the vCenter server to the Horizon environment, I got an error: "Certificate validation failed" and gave me no option to accept the certificate.  This was more than a little confusing because the vCenter server had a proper certificate signed by the enterprise CA and we verified that our Connection Server, as a domain member, trusted that CA and could even browse to vCenter via the web browser with no certificate issues. So, I did what we all do in this sort of situation; I started digging through the the logs.  Eventually, I found the line that I needed in the C:\programdata\vmware\vdm\logs\debug-<date>.txt log file on the Connection Server (after searching for my vCenter server's name to help narrow down the contents of the log): "Permission to perform this operation was denied." Well, that struck me as int

Error during Pre-Checks for vCSA Upgrade from 6.0 to 6.7

Hi everyone - I was helping a customer upgrade their vCenter Server Appliance from 6.0 to 6.7 and we came across a bit of trouble.  During the pre-upgrade checks phase, our logs revealed these errors: No file found matching /etc/vmware/install-defaults/cm.url No file found matching /etc/vmware-vpx/vcdb.properties No file found matching /etc/vmware-vpx/vc-extn-cisreg.prop Googling around revealed some possible DNS related issues, but we doublechecked that all of our DNS records were good so figured that was unlikely to be the issue.  So, after some more unfruitful research, we decided to check on the current version of the vCenter server.  It was a very early version of 6.0.  Lacking further direction, we went ahead and used the management interface (via port 5480) to download the latest 6.0 updates.  After those were applied, we tried the 6.7 upgrade once again and everything went great! So, if you come across those error messages, you may just need to upgrade to a newer version o

Deploying the vCloud Director OVAs from the Command Line

I've recently had the opportunity to do some work with a vCloud Director deployment, which has been a lot of fun! We've been working on a lab environment at the moment, and we want the ability to quickly redeploy the lab now and we want to be able to reliably deploy a similar configuration into production later. So, to that end, I spent a bit of time figuring out how to deploy the VCD Appliance via the CLI, and I'm ready to share my results! I started by spending some quality time with the Deploying vCloud Director with the OVF Tool Guide  to get an idea about what options I was going to need. There's a lot of options in there, and there's a moderate amount of variety to their syntax! After looking over the various options, it looks like we can basically break down the option syntax into 3 parts: a Paramter, a Name, and a Value. Various options use these parts in different combinations. Let's look at these lines from their example: --allowAllExtraConfig --d

Complex vRNI Queries

Hi everyone - this'll be a short post, as I just wanted to write some some quick notes about queries in vRealize Network Insight.  VMware has a great document on some Advanced vRNI Queries ; I wanted to talk about the keyword "in" and "of" and record how I've used them for some other interesting queries that aren't on their list. "In" allows you to search in a list so that you can take advantage of nested queries.  "Of" allows you to specify a property of a query (which can be useful when you want to search a list based on that property). So, if I want to see all network flows that hit firewall rules in a particular NSX section, I could use this query: flow where firewall rule in (nsx firewall rule where section name = "My Critical Section") That will give me a list of all flows that have hit any firewall rules in that section.  That's actually the query that I needed to solve my problem, but I solved it with &qu

Accessing the vCloud Director API

I've been working on a vCloud Director environment recently and need to use the API for my current project.  Well, I'm not a big API guy, so this has been a good learning experience for me!  The first hurdle that I had to overcome was authentication, and since I didn't find that to be super well documented, I figure that I should put my notes up here.  So, here's how I get authenticated to vCloud Director's API via PowerShell (because, of course PowerShell!). First things first, you've got to figure out what credentials you want to use.  The most basic way to authenticate is with a local account (rather than an LDAP account), but you need to append a scope to that account name to get logged in.  If the account is part of an Organization, you can use that Organization's name, but if it's a system administrator, you'll need to use "@system" instead. Next, you'll need to Base64/UTF8 encode your credentials in order to pass them success

Generating an NSX Firewall Rule Report

One of my customers wanted an easy way to generate a report of all of their NSX Firewall rules as a CSV.  So, simply use get-nsxfirewallrule | export-csv and call it a day, right?  Unfortunately, the NSX Firewall Rule objects are a bit too complex to directly export as a CSV, so I put together a short script to unpack them.  Nothing's too complex here, but sometimes it's nice to have an easy script that just gives you the information that you need! Check out the script on Github !

PowerNSX Set-NSXFirewallRule AppliedTo Support

As you've seen from my recent blog posts, I've been doing a lot of NSX work recently.  One of my customers has been working on a distributed firewall redesign and, as part of this effort, we determined that we needed to change the "AppliedTo" field for all of their existing firewall rules.  Because they have hundreds of rules, we knew that we'd need some sort of automated solution, lest we introduce unknown errors through our attempts at making these changes by hand.  Given my past experiences with PowerNSX (and the fact that it's my primary NSX management interface), I figured that this would be super easy, barely an inconvenience.  Whoops! PowerNSX is great, but it's a community tool at its core.  This means that the feature set that it has is limited to the intersection of features that the community has needed and those that the community has spent the time developing.  So, 99.999% of what I need is already there and I usually don't even need to