This section looks at what is new in the world of software (Operating Systems included) and how to take best advantage of what is out there.
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.
While iterating through an issue with our Ruckus SmartZone (with Ruckus R510 Access Points) controllers I was looking for a way to see when the Access Points had applied the new configuration; lone behold it’s quite easily done through both the CLI and the GUI.
Anyone who has used the new SmartZone controllers will know all too well that’s it’s not the fastest GUI to work with – thus if you have the option I’d suggest you go with the CLI method which is very responsive (and much more consistent!).
Via the CLI
Via the GUI
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).
While provisioning some new Ruckus R510 WAPs onto our SmartZone 100 (188.8.131.52.675) we’ve had a number of cases where the WAPs will reboot for their firmware update but will not proceed beyond that point. In particular the PWR and CTL lights stay lit but the radio lights do not come on at all.
Looking in Access Points > Affected WAP > More > Tunnel Diagnostics (we’re using AP tunnelling) I note errors along the lines of
ifconfig: gre1: error fetching interface information: Device not found
cat: can’t open ‘/proc/rksgre/gre1/stats’: No such file or directory
cat: can’t open ‘/proc/rksgre/gre1/cache’: No such file or directory
cat: can’t open ‘/proc/rksgre/gre1/cfg’: No such file or directory
cat: can’t open ‘/sys/kernel/debug/qca-nss-drv/stats/*’: No such file or directory
The solution thus far has been pretty simple – factory reset the WAP by pressing and holding the RESET button in the back for 6+ seconds. It’ll go through a process of about 5-10 minutes and thus far have been coming back in a functional state.
Today I had the pleasure of presenting at the Oxford ICTF Conference on Multi-Factor Authentication and Password Stores with Smart Cards and YubiKeys, the video recording is online now here – https://youtu.be/WGtCxS2YFNA and the presentation can be downloaded through the link below.
Presentation.pdf (5.5 MiB, 917 hits)
Having recently changed from using PowerShell ISE to VS Code I’m still discovering all the super awesome new features of it (be sure to get a copy of the Keyboard shortcuts from this page – https://code.visualstudio.com/docs/getstarted/keybindings). To get started I’ve changed the default new file language to PowerShell (not that you can’t change it to anything else though!).
To do this follow the short guide in the screenshots adding in the line shown in the gist below.
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 – https://www.nartac.com/Products/IISCrypto) 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, 765 hits)
Presentation (PDF) (4.9 MiB, 715 hits)
Microsoft have published this blog post – https://cloudblogs.microsoft.com/windowsserver/2018/03/29/windows-server-semi-annual-channel-update 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 – https://www.youtube.com/watch?list=PLRxbdlgJzwyjAf820T0u4GpP0E01a9LEX&v=u-GVJ_0VuRM
Slides as PowerPoint
1 Intro (4.3 MiB, 913 hits)
2 MDT (85.2 MiB, 1,067 hits)
3 PowerShell (27.5 MiB, 905 hits)
4 PRTG Network Monitor (47.5 MiB, 951 hits)
5 OpenVAS (32.9 MiB, 780 hits)
6 WSUS and Chocolatey (60.3 MiB, 940 hits)
7 NPS and VLANs (10.7 MiB, 1,097 hits)
Slides as PDF
1 Intro (2.0 MiB, 893 hits)
2 MDT (2.2 MiB, 1,174 hits)
3 PowerShell (1.8 MiB, 1,460 hits)
4 PRTG Network Monitor (3.2 MiB, 966 hits)
5 OpenVAS (2.3 MiB, 960 hits)
6 WSUS and Chocolatey (2.9 MiB, 1,195 hits)
7 NPS and VLANs (1.4 MiB, 1,064 hits)
Stay tuned over the coming days for the scripts that are mentioned through the video which will be linked to from this post.
One of the often forgotten about features of gpresult is that it can output reports as HTML format (in a similar format to Group Policy Modelling) as well as to the command line – simply use the /h switch followed by a path. This includes much more useful data including how long it took to apply various aspects of the policy.
In the example below we can see that Group Policy Infrastructure took much longer to apply than expected (normally only a second or two), you can then dig into the cause by clicking the View Log link to the right which pops out even more detail to dig through. In this case the cause of the slow policy application appeared to be old ADM files (Windows XP era) being included with the policy; deleting the files resolved the issue.