Servers power many organisations and are even making their way into homes (even if it is a simple NAS box). With more RAM then you could even imagine (I have to admit I’m a RAM addict) and processors that make the latest and greatest gaming PC look minuscule in comparison it is these mighty machines that make the world go round.

For some time there have been plenty of examples of backing up Palo Alto Firewalls with curl commands (extracting the files using the XML API) however that may not sit well with some Windows administrators who want to use PowerShell. As such I’ve put together the BackupPANNGFWConfig repo on GitHub which contains the scripts to get ahold of the API keys needed and then to perform the backups for a series of firewalls.

To get the scripts drop by the link below and for the configuration see the screenshot sequences in this post. You will need a basic understanding of Palo Alto Firewalls, PowerShell and Windows Server to work through these steps.

Super important note, this script is configured to use a TLS1.2 connection to the firewall as well as only allow connections to a firewall with a trusted security certificate – if you jump on the web management interface of the firewalls from the server that you are running the script from you should see the ‘secure’ padlock icon in the address bar.

With the scripts all configured you will then want to configure a scheduled task on the server to take these backup files on a regular basis.

Bit of a crazy issue when deploying a new Ruckus wireless network – in first suspecting an issue with the controller software or perhaps some kind of access control list blocking traffic it turns out that the default Windows Firewall rule for allowing NPS traffic is broken in some fashion.

Having tried this (and it working fine) on Windows Server 2012 R2/2016 it really does appear to be isolated to Server 2019.

Discovering this came about with a few traffic captures combined with the wonderful NTRadPing tool. The fix is to manually create the rule, see the screenshots below on how to do this.

After a great many years since Custom RemoteFX RDS Farm it’s time for something new! After much discussion and looking at the working practices at my current place of work we’ve decided to go all in with RDS and to support that we’ve got 3 new servers to run it on.

2x 1U rack mounts to go in our main server room with 1x tower for our DR room.

Photos below!

For a little while now we’ve had issues with the uniFLOW Server service (version 5.3) not starting in a timely fashion (2hrs+).

After a harrowing tale of working with their support going in circles looking at issues with SQL Server and suchlike we worked out that the issue seemed to be caused by stale files at ‘C:\Program Files (x86)\Common Files\NT-ware Shared\ActiveJobs’ some of which were many months old or 0KB in size.

Ultimately the solution was to stop the Uniflow Service (force quit it using Task Manager if it’s still in a broken ‘starting’ state) and then delete the contents of that folder with the exception of the readme_activejobsfolder.txt file (which mentions that you shouldn’t do anything to these files!) and then start the uniFLOW Service service (which started up in a few minutes).

In putting together a small RDS (Session Based) environment on Server 2016 today today I kept running across the error message below during the installation.

Failed: Unable to install the role services.

After much back and forth between forums and event viewer it turns out our default policy to disable TLS 1.0 on servers was the issue. Enabling TLS 1.0 (through the registry or with the fantastic IIS Crypto – ended up sorting the issue for us.

Thanks to the organising committee of the (Oxford and Cambridge) College IT Conference 2018 held at the RAF Museum (Hendon) for the invite to talk about PowerShell and Server Core! As promised the video from the presentation is now up on YouTube; in addition the slides as PowerPoint and PDF can be seen below.

  Presentation (PowerPoint) (28.5 MiB, 442 hits)

  Presentation (PDF) (4.9 MiB, 418 hits)

30/03/2018 Update

Microsoft have published this blog post – which clarifies the difference between the Long-Term Servicing Channel (Server 2016/2019/so on) against the Semi-Annual Channel. Do have a read!

With thanks to the 50 staff from across the University for attending please see below the links to the videos and PowerPoints of the day!

Direct link to Playlist –

Slides as PowerPoint

  1 Intro (4.3 MiB, 561 hits)

  2 MDT (85.2 MiB, 611 hits)

  3 PowerShell (27.5 MiB, 543 hits)

  4 PRTG Network Monitor (47.5 MiB, 537 hits)

  5 OpenVAS (32.9 MiB, 491 hits)

  6 WSUS and Chocolatey (60.3 MiB, 515 hits)

  7 NPS and VLANs (10.7 MiB, 682 hits)

Slides as PDF

  1 Intro (2.0 MiB, 565 hits)

  2 MDT (2.2 MiB, 728 hits)

  3 PowerShell (1.8 MiB, 605 hits)

  4 PRTG Network Monitor (3.2 MiB, 629 hits)

  5 OpenVAS (2.3 MiB, 596 hits)

  6 WSUS and Chocolatey (2.9 MiB, 705 hits)

  7 NPS and VLANs (1.4 MiB, 660 hits)

Stay tuned over the coming days for the scripts that are mentioned through the video which will be linked to from this post.

This entry is part 4 of 4 in the series A Windows SysAdmin installs and uses OpenVAS

In my environment all of our network connected devices are configured to respond to PINGs; this mainly comes about from using PRTG Network Monitor to confirm that devices and services are up even in the most simple of fashions. The same also applies to client PCs which through Group Policy are configured to reply to PING. Thus to save OpenVAS some work while doing it’s scans I’ve got a custom scan configured (which will be used in later blog posts) that will only scan hosts which reply to PING.

Have a look at the screenshot sequence below to see how to configure such a scan.

A little bit of fun today with Milestone XProtect (in our case the express version) today; with the goal of improving our documentation I wanted to somehow obtain a list of all of the hardware devices (and to some degree the cameras) including there names, MAC addresses and IP addresses from our XProtect server.

Lone behold the configuration.xml file typically stored at “C:\ProgramData\Milestone\Milestone Surveillance\configuration.xml” held just the information I wanted; a little bit of PowerShell later and I had CSVs with the information in a human readable form.

To do the same on your server follow the guide using the Export-MilestoneConfig.ps1 script show below.

Download Export-MilestoneConfig.ps1 (download from GitHub)

Not the first time I’ve run into this issue and probably won’t be the last! While building a new Windows Server 2016 (Full) Microsoft Deployment Toolkit server when attempting to run the ‘Update Deployment Share’ wizard I was getting the following error message.

Unable to mount the WIM, so the update process cannot continue.

The solution is simple; if you are running this machine on Hyper-V (presumably other Hypervisors as well) you will need to shutdown the VM, disable Secure Boot (on the VM only) and then power it back on. The next time you run the wizard it will complete as normal.

The error message in full context for reference.

=== Making sure the deployment share has the latest x86 tools ===
=== Making sure the deployment share has the latest x64 tools ===

=== Processing LiteTouchPE (x64) boot image ===

Building requested boot image profile.
Determining if any changes have been made in the boot image configuration.
No existing boot image profile found for platform x64 so a new image will be created.
Calculating hashes for requested content.
Changes have been made, boot image will be updated.
Windows PE WIM C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us\winpe.wim will be used.
Unable to mount the WIM, so the update process cannot continue.

=== Completed processing platform x64 ===


=== Processing complete ===