This Patch Tuesday related posting details some of the suggested testing guidelines for this July 2022 C release of patches from Microsoft.
Key Testing Scenarios: Given the large number of changes included in this July patch cycle I have broken down the testing scenarios into a high risk and standard risk groups:
High Risk: These changes are likely to include functionality changes, may deprecate existing functionality and will likely require creating new testing plans:
Core printing functionality has been updated this month:
- Install new V4 print drivers on a local machine and print.
- Test new V4 printer connections using client and server and print.
- Test existing v4 printer connections
- GDI rendering and printer drivers
The core changes included in this month’s Patch Tuesday release related to how Microsoft supports time stamp checking for kernel drivers. Testing applications that require digitally signed binaries is key for this release cycle. The big change here is that unsigned drivers should not load. This may cause some application issues or potential compatibility problems. We recommend a scan of the application portfolio, identifying all applications that depend upon drivers (both signed and unsigned), and generating a test plan that includes installation, application exercising and uninstall. Having a comparison between pre and post patched machines would be helpful.
The following changes are not documented as including functional changes but will still require at least “smoke testing” before general deployment of this month’s patching:
- Test scenarios that utilize Windows DevicePicker Almost impossible to test – as most applications use this common class. If your internally developed applications pass their basic smoke test, then you are fine.
- Test your line of business applications that reference the Microsoft mobile CDP API’s. If you have internally developed desktop applications that communicate with mobile devices, then a communications check may be required.
- Test connections to the rasl2tp server. This means finding and then testing applications that have a dependency on the RAS mini-port driver over remote or VPN connections
And Curl. Specifically, CURL.EXE: a command line tool for sending files via HTTP protocols (hence “client URL”) has been updated this month. Curl for Windows (the one that is being updated this month) is different from the Open-Source project curl. If you are confused the Curl project team offers this,
“The curl tool shipped with Windows is built by and handled by Microsoft. It is a separate build that will have different features and capabilities enabled and disabled compared to the Windows builds offered by the curl project. They do however build curl from the same source code. If you have problems with their curl version, report that to them. You can probably assume that the curl packages from Microsoft will always lag behind the versions provided by the curl project itself.”
With all that said, we recommend your teams that use the curl command, sourced from the Windows supported branch, give their scripts a quick test run.
Microsoft has published a testing scenario matrix that for this month includes:
- Use physical machines and virtual machines
- Use BIOS-based machines and UEFI-enabled machines
- Use x86, ARM, ARM64, and AMD64 machines
Noting that for each of these testing scenarios, a manual shut-down, reboot and restart is suggested.
Happy Testing!
