Monthly Archives: January 2022

Windows Software Deployment

Windows software installers have not changed much since the days of XP, much software is distributed as a .exe which then contains a self extracting installer for putting file into the appropriate place and adding registry entries etc. The .msi file format brought some standardisation, and now with Intune, there is a new format, the intunewin.

The intunewin format is a container format for the files for the software installer, which is created by the packager, and is then encrypted and signed by Intune with a certificate that can be verified by an endpoint that has joined to the O365 tenant. There is an install and and uninstall command that needs to be set for the intunewin file in Intune for the actual deployment.

There are many blog posts across the Internet that cover the installation of specific applications that they have had issues packaging for Intune, frequently using an install.cmd to perform tasks that are not able to be set as a command line option. For one application that I recently packaged, I created an install.cmd that deployed two firewall rules before then installing the software with a msiexec /i etc. Without these firewall rules in place, on first running of the application, a Firewall popup (that a user is not able to accept) woudl occur, and the applicatio n would not function correctly. The application vendor a/ does not support Intune, and b/ suggests that installs should be performed by an Administrator. With the rise of MDM for managing endpoints, Application vendors need to start packaging their Windows software with a similar mindset to creating IOS/Android software, everything packaged in a simple to deploy  manner that can deployed with modern deployment methods.

 

 

 

 

What time is it ?

Time is quite important for computers, for some purposes, to be synchronised to within 5  minutes is accurate enough, for other purposes milli, micro, nano or femto seconds are required.

When comparing logs across multiple devices, having devices do not have time synched can make tracing events harder than it needs to be.

One can add a single time standard to get around this, but for NTP to work well, there should be at least 3 standards, one could however configure a GPS time server that takes time from GPS (or to be precise PPS to get sub millsecond accuracy) and also uses external NTP servers to confirm that the GPS output is “sane”, A raspberryPi can do this quite well. https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/

To go “better” than NTP, the next step along the ladder is PTP (Precision Time Protocol), which has a very different way of workign to NTP, in that a GM (Grand Master) clock is the single source of truth in a PTP domain, one can then have that GM clock accessed by secondary level “boundary” clocks to act as a distribution layer. While a raspberryPi can run PTP, the jitter from the raspberryPi is at a level where it can be seen when comparing to dedicated devices, or say a Solarflare card that is fed with a “clean” PPS in, it is however good enough to see the change in one way delay when the path goes over 1, 2 or 3 Ethernet switches.