Virtually Jason

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 !

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 ...

I've been working with one of my customers to implement the NSX Distribtued Firewall via Security Policies instead of hand-crafted rules.  For auditing and reporting purposes, we needed to be able to display all of the policies that have been created and the DFW rules within each one.  Ideally, we'd need to be able to generate this report on demand, with real-time data... and since the NSX GUI doesn't make that easily visible, I figured that I should put together a script to do it for me! Enter the summarize-NSXSecurityPolicy.ps1 script.  This script uses PowerNSX to get all of the defined Security Policies in the environment, then builds a table with one row per DFW Rule.  Each row contains several columns, including one for the policy that defines the rule, so we can easily filter the table to show what's going on with specific policies or we can easily search it to find a policy that involves specific traffic.  That later use case is almost certainly more im...

Hey everyone - I've been helping a customer implement their NSX Distributed Firewall recently.  I'm not a big fan of the GUI, but I can do just about everything that I need to do through PowerNSX, which I've found much faster and easier to manage... until I started working with Security Group membership exclusions. NSX follows a fairly sophisticated process for determining what objects are members of a given Security Group.  First, it checks the rules in that Security Group's Dynamic Membership section and adds all of the specified objects to the list (this can be a computationally expensive process, so you probably don't want to use a lot of dynamic membership rules).  Next, it checks the list in that Security Group's Static Include section and adds all of the specified objects to the list (this is a cheaper operation and should be the go-to group membership method).  Finally, it checks the list in the Exclude section and removes those objects from the list. ...

I do a lot of work with PowerCLI and my favorite text editor is Notepad++ .  Recently, I've been adding more modules to my repertoire ( PowerNSX and PowerVRNI , I'm looking at you!) and I've finally decided that I need to add all of these modules' cmdlets to my syntax highlighting in NPP.  The proper way to do this is to define a custom language and add everything to it.  This can be done through the GUI (yuk) or by editing a custom language xml file. Unfortunately, there's no way to clone an existing language as a start for a custom language (or at least, I couldn't find a way to do it).  Even more unfortunately, the custom language definitions file syntax is pretty different from the inbuilt ones, so you can't just copy and then edit the XML from the already existing PowerShell language. Not if you want to do it the proper way.  It looks to me like I can trivially edit my default langs.xml file (where PowerShell is defined) and add an arbitrary set o...

I've been helping one of my customers set up a proof of concept NSX implementation, which has involved configuring and then destroying several firewall designs.  In order to speed up this process, we've had to get pretty good at using PowerNSX to script out the creation of those NSX firewall rules (and other security objects). First, how do you get PowerNSX?  Just like PowerCLI!  Open up your PowerShell window, then use this command: Install-Module PowerNSX Now that you've got PowerNSX installed, take a moment to look at what it does for you.  Look at all of the available cmdlets by using: get-command -module PowerNSX There's a lot going on there!  In general, the PowerNSX cmdlets use the normal PowerShell verbs: get, set, add, remove, and new, and the nouns are prefixed with NSX.  So, if you're using tab completion to figure out what command you're doing, <verb>-nsx... is usually a pretty safe place to start.  For example, if I want to get...

I've recently had the opportunity to do some work with NSX during some server migrations.  That work has been fairly repetitive for each group of servers that we're migrating so, you guessed it, I looked for an easy scripting/automation solution, and PowerNSX proved to be the right tool for the job! As the name implies, PowerNSX is the NSX portion of PowerCLI.  Installing it is a breeze - just use a relatively up-to-date PowerShell window and fire off install-module PowerNSX .  That'll give you access to a whole set of NSX-oriented PowerShell cmdlets.  It's still in beta, so there's a lot of rough edges, but it's still proven to be an excellent tool for many tasks, including manipulating large numbers of VM Security Group Membership settings and creating Firewall rules. One of those "rough edges" involves cached instances of objects.  For example, if I want to add a bunch of VMs to various security groups based on a CSV input, I'd often write ...