You can get the script to export the value from a computer here.

The main thing the script does is call WMI to get the DeviceHardwareData value.  It’s a real shame that you can’t generate this data yourself.  In Microsoft’s own words:

References:

• Gathering Windows AutoPilot hardware details from existing machines
• Use the step-by-step guide to add Autopilot devices and profile
• DevDetail CSP
• Adding devices to Windows Autopilot

One of our customers reported that they intermittently lost access to the Office Templates directory.

Sometimes it worked well, and sometimes “it was gone!”.

The environment was Windows 10, with Office 2016.  The Office Templates were located on DFS shares (ie. the location was \\ALargecustomer\DFS\OurTemplates)

What could it possibly be???

Continue reading →

The initial thought was “it’s another ‘SMB1 is disabled’ causing connectivity problems” problem.

Except it wasn’t.

The issue was that our customer reported that they could no longer connect to their NAS device.

With Windows 10 v1709, Microsoft disabled Guest Access.  In their words:

Cause
This change in default behavior is by design and is recommended by Microsoft for security.
 
A malicious computer that impersonates a legitimate file server could allow users to connect as guests without their knowledge. Microsoft recommends that you do not change this default setting. If a remote device is configured to use guest credentials, an administrator should disable guest access to that remote device and configure correct authentication and authorization.
 
Windows and Windows Server have not enabled guest access or allowed remote users to connect as guest or anonymous users since Windows 2000. Only third-party remote devices might require guest access by default. Microsoft-provided operating systems do not.

– Guest access in SMB2 disabled by default in Windows 10 Fall Creators Update and Windows Server 2016 version 1709

For the small number of end users who will need to connect to a third-party NAS, we’ll probably manage it via exception.

We had a bunch of newly built Windows 10, version 1607, PCs where App-V 4.6 failed to start.

It was our own fault, App-V 4.6 is not supported on Windows 10.

It did work, until we started using Windows 10 v1607.  An upgrade to v1607 worked fine.  It was a new build where App-V 4.6 didn’t work.

It’s not as if we could ask Microsoft.  Unsupported product is unsupported.

Much Googling occurred to dig up this article
Driver Signing changes in Windows 10, version 1607.

Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal. OS signing enforcement is only for new OS installations; systems upgraded from an earlier OS to Windows 10, version 1607 will not be affected by this change.

Existing drivers do not need to be re-signed. To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate issued prior to July 29th, 2015 will continue to pass signing checks on Windows 10, version 1607.

So there is the answer.  We were using App-V 4.6 SP3 HF05.  The sftplaywin81.sys file was signed on 22 September 2016.  Which is later than July 29th, 2015.

We downgraded to HF03, as sftplaywin81.sys was signed on the 16th August, 2014. 

Which fixed the problem of App-V not working.