NetScaler MAS: Resetting nsroot password

1vst4d
Intro

NetScaler MAS represents a very versatile and powerful tool. If you have NetScalers, I recommend you give it a try. As of this writing, if you have 30 or fewer VIP’s configured on your NetScalers, you can use all the features of MAS (confirm with your Citrix Sales Rep). So, let’s say you want to make some changes to MAS and find that a former employee has removed write access to your group and the nsroot password is unknown. What do you do? Citrix provides documentation on resetting the nsroot password on NetScalers, but nothing on MAS.

Get your Mr. Robot on!

We were able to follow most of the procedure in https://docs.citrix.com/en-us/netscaler/10-1/ns-system-wrapper-10-con/ns-ag-aa-intro-wrapper-con/ns-ag-aa-reset-default-amin-pass-tsk.html

This was a virtual machine on XenServer, so I connected to the console

  1. Connect to the virtual appliance via XenCenter..
  2. Reboot the NetScaler MAS.
  3. Press CTRL+C when the following message appears:
    Press [Ctrl-C] for command prompt, or any other key to boot immediately.
    
    Booting [kernel] in # seconds.
  4. Run the following command to start the NetScaler in a single user mode:
    boot -s
    Note: If boot -s does not work, then try reboot — -s and appliance will reboot in single user mode.

    After the appliance boots, it displays the following message:

    Enter full path name of shell or RETURN for /bin/sh:
  5. Press ENTER key to display the prompt, and type the following commands to mount the file systems:
    1. Run the following command to check the disk consistency:
      /sbin/fsck /dev/ad0s1a
      Note: Your flash drive will have a specific device name depending on your NetScaler; hence, you have to replace ad0s1a in the preceding command with the appropriate device name. In my case it was ad0s1a
    2. If you receive the following after running the above command:
      fsck: Could not determine filesystem type
    3. Run this command to resolve:
      /sbin/fsck_ufs /dev/ad0s1a

      You should see the following (select Y for all the prompts).nsroot1

    4. Run the following command to display the mounted partitions:

      df

      If the flash partition is not listed, you need to mount it manually.

    5. Run the following command to mount the flash drive:

      mount /dev/ad0s1a /flash

  6. Run the following command to change to the nsconfig directory:
    cd /flash/mpsconfig
  7. Create a hidden recover file in this directory
    touch /flash/mpsconfig/.recover
  8. Reboot the MAS
  9. Once the reboot completes, enter in nsroot/nsroot for the username and password (this may take a couple of minutes before you can login with nsroot.
  10. Login to the MAS web page with nsroot.
  11. Change the nsroot password and make other administrative changes.

Thanks,
Alain

Advertisements

PowerShell: Get XenApp Load and Create Report (Again)

load2.jpg

Intro

Nostalgia is ruling movies and TV these days. Mystery Science Theater 3000 has returned from the dead to Netflix. I’m still getting through he first episode, so I’m still withholding judgement. In the spirit of going back to the well and rehashing old ideas, I’ve revisited my XenApp Load/Report script again.

Changes

  • I’ve moved the code to my Github account
  • I’ve removed the Logon Status column and replaced it with the server’s worker group
  • I’ve sorted the report by the Worker Group
  • I fixed the formatting to display all the columns even if the first server was down. Before, if the first server queried by the script was down, then only the servername and status would show for all servers.

The Report

The report can be generated and sent to your browser of choice (the script defaults to Internet Explorer). In addition, you can set the SMTP information in the script have have it emailed.

load1

The Script

Get the script from Github

PowerShell: Cleanup Reboot script

cleanup-reboot

Intro

If your environment leverages Provisioning Services and is fairly large, you may run into issues with servers coming up but not allowing any users to login. The fix we implemented is to reboot those servers after it’s clear that they will not allow users to login (usually sometime mid-morning when most of our users have logged in). This was  a manual process and I wanted to find a way to automate this until we could change our reboot schedules or find a resolution. In this post we’ll explore using a script to catch these unresponsive servers.

Scenario

Your reboot script ran last night and you find that the next day there are a handful of servers that report to the farm, but do not have any users attached. You’ve checked the obvious problems/issues and the event log isn’t any help. The only solution seems to be another reboot. Once the system comes up, users are able to connect.

In order to automate the reboots, we have to determine the criteria that identifies a server as having a problem and not just an idle server.

  1. It is mid-morning and most of our users are logged in and using Citrix. The server has no users connected even though the load evaluators and login behavior should allow users to connect.
  2. The server is marked as ‘Online’ when using the PowerShell Cmdlet get-xaserver.
  3. The server is a not in our excluded list (more on this below)
  4. The server has a high load even though it is hosting no users.

I got one two words for you…Worker Groups

You will have to edit the $WORKERGROUPS variable to list the Citrix Worker Groups (WG) you wish to check for zero-user servers. The list can be separated by commas. Optionally you can also edit $EXCLUDESERVERS to have the script ignore servers you do not want checked for zero-users.

The script will iterate though the servers in each WG. This is done with 2 nested foreach loops.

The script confirms the Worker Group is valid and then iterates through the servers in the WG. It checks that the server is considered Online and not a member of the $EXCLUDESERVERS list. It then confirms the server has no users connected and then checks to see if the load is greater than or equal to 3500. In our farm, this was a common characteristic for these zero-user servers. You may need to change this to better reflect your environment. I setup a scheduled task to run this script every day around 10Am and it has automated an administrative task freeing me up to write blogs about PowerShell.

NOTE that this script does not actually reboot the server. We have another script that runs all day looking for servers that are set to ProhibitNewLogOnsUntilRestart. This secondary script checks that no users are logged into a server set to ProhibitNewLogOnsUntilRestart and then reboots it. You could edit the script above to add this.

What about reporting?

If you wish to receive an email report of which servers were set to ProhibitNewLogOnsUntilRestart uncomment the above lines in the script. You will have to provide an SMTP server and a single or list of email addresses. Here’s an example of the email report:cleanup-reboot

The Script

You can download the script from Github.

Thanks for reading,
Alain