Using PowerShell (Invoke RESTMethod) and NetScaler NITRO – Example

Well, as the IT field goes it is a constant world of change. I have learned that no matter how cool or effiecient the solution i have created is or how many hours i have poured into it, i am not married to it. So it goes without saying, the script i created to pull configured STA and Web Interfaces from the Citrix Secure Gateways needed to be retired and i had to find a way to get the same type of data from the NetScalers.

Persistence paid off and I came up with a way to get it by leveraging PowerShell 4.0 and connecting the NITRO interface on the NetScalers. This script is nothing too glamarous. It basically grabs items from the ‘running’ configs and parces out just what i want. In this case all i want from the NetScalers are:

• The vServers configured,
• The STA’s the vServer is configured to use (and IP)
• The Web URL that leverages the STA’s
• Policy is also listed as that is where i get the URL (Websites) affected

We have about 8 Netscalers (regional not clustered) and i have it set to report on all of them at the same time so i can see how they compare to each other. I am posting my script to help others who may need something similar.

Here is the script: NSDocumenter (in DOC format)

Update to the Rolling Reboots scripts

I have updated my rolling reboot script to include proper coding for Event log entries and Deletion of items in the windows directory that are greater than 30 days old prior to reboot. I also included a ‘TestMode’ that will allow for an accelerated run in a test farm. There are also some future expansions i was playing with to capture times when a server does not completely come out of its reboot. i am waiting for the team to make a statement as to what they want.

if you want to go directly to it here is the link: Clean_FarmReboots_v3

Again, if anyone wants to try this script you will need to do the following.
1. look at the ‘GLOBAL’ variables and make changes as necessary.
2. you will also need to understand there are two workgroups in play here: Primary, Contingency this is hardcoded (but feel free to change to suit your needs)
3. also check the $testmode variable to ensure it fits your needs.

i have about 12 farms that will run this script (6.0 and 6.5 currently and more in the wings). it is placed on the zdc and a scheduled task runs this script (using a domain service account to run the task)

I expect the next version will be set to include 7.5…. will let you know….

Re-organization of the page

I am going through and reorganizing this blog since it is starting to be more than just a place to post work stuff. Please bear with me through these changes.

With NetScaler on the way, we still have a need for Web Interfaces….

The issue:  

So i work in a fairly large and complex Citrix environment. We have currently have about 210 Servers involved in someway delivering applications via citrix ( this includes old CSG’s, Web Interfaces, not to mention XenApp servers themselves). As any responsible entity, we have regular patch cycles for all our servers and we are a 24×7 shop. so you can imagine we have enough servers in the xenapp farm to cover the load during the patch cycle and we are able to shed the load on the servers at will.

But what about the web interface servers and the associated gateways….

Due to some much needed reorganization I am moving this post to its own page..XenApp Web Interface Controls

XenApp ordered reboot script.

Like many others in the XenApp community, I have had to have a way to do an orderly reboot of servers.  We had many requirements that prevented us from using the policy settings in XenApp 6.0/6.5 (which would be nice)

So here is the scenario (there are a lot of rules in the organization governing what can talk to what, so we have to keep a number of things separate):

• 12 Regionally separated farms.  (primary/contingency scenario – need to run on 1/2 of the servers at any given time)
• 100 (roughly) XenApp 6.0/6.5 servers
• Requirement to have the environments available 24/7 (no down time)
• Work with one workgroup/one server at a time to reduce overall impact to end uers.
• Control the reboot window with the ability to Abort on any specific or group of servers.
• Notifications of reboot process and when a server is returned to service.
• Not have another service or script that has to run constantly.
• Reboot ALL servers in a farm specifically the one controlling the reboots and still receive notifications about reboot status.

 

Here is a link to the page with more details and code: Scripted XenApp Reboots

Daily Farm Status reports for XenApp

This is a script that Alain Assaf created and based on his base i was able to modify it to work on following platforms:

XenApp 4.5

XenApp 6.0

XenApp 6.5

There were a couple of places where i needed to modify the code to compensate for the different versions of XenApp.  But once i was done i distributed a Scheduled task to one server in every farm (14 farms, 4.5, 6.0, 6.5) that would launch this script from one shared location (one script to report on all!).. What’s cool is i have just one place to send updates to the script.  What’s bad about that is i have to take into account all of the differences between what is availible in the powershell command set.

Since some wanted to see the whole code here it is.

(UPDATED:  1/14/14 – Here is the link to the minor revisions)

updated to include ZDC identification and Days since last reboot.  not important to everyone but something our team needed