Windows 11 and SQL (Express) issues

SQL Express issues on Windows 11

Due to a change on how Windows 11 presents the disk sector size, you can have issues with SQL or SQL Express after your upgrade or even on brand new installations.

SQL might just fail to start after an upgrade, with the Event Viewer Application Log Error 1000 similar to the below one:

This is especially true for Samsung SSD 980 – be aware – the SSD 980 Pro does not have this issue, just the SSD 980. There are other OEM versions of it that have the same issue and actually a bunch of other disks.

The root cause is that the devices report the true sector size, what causes SQL to fail. This is still true with SQL Express 2019 – earlier versions as well.

As described in this Microsoft article, you can add a registry key and reboot to make Windows 11 behave like Windows 10 and earlier Windows versions.

Of course, alternative you can either install SQL on another disk drive or replace the drive with one that does not have these compatibility issues.

It remains unclear if there will be updates to this in the future from either Microsoft of the disk vendors like Samsung in the future. For now, this simple registry adjustment fixes the issue.

Reboot after the registry adjustment for the change to take effect.

Windows 10 Build 2004 / 20H1 – SMBv1 network drives not connecting

SMBv1 network drive not connecting

The newest builds and updates can possibly break some Windows 10 network connections. Saw this specifically in a situation with a SMBv1 drive that was connected via FQDN per GPO.

Windows was not able to connect to the drive, looking at NET USE all you saw was reconnecting.

Connecting to the same share via HOSTNAME and/or IP worked just fine, as well as engaging the UNC path.

The solution to this eventually is a simple registry adjustment, that has to be done in the user-profile HKCU area, so no advanced rights are needed.


  1. open REGEDIT
  2. go to HKCU\Network
  3. select the key with the drive-letter you have issues with
  4. add a new REG-DWORD
    2. Decimal 1 or DWORD 00000001
  5. Reboot

Your network drive should work normal again.

Background and Explanation:

The PROVIDERFLAGS instruct Windows to reconnect the SMBv1 network drive, more or less. It eventually did not matter if it was connected per FQDN, IP or HOSTNAME – is was the reconnect that the GPO implied, respective the NET USE /PERSISENTENT:YES switch. If you would use a script – netlogon script – you could just determine the drive as /PERSISTENT:NO and not see the issue either as well as solve it.

Eventually this is specific to SMBv1 and I can’t warn enough about the security risks this protocol has. Still – there are here and there systems that still need to stick around – hopefully secured by firewalls and even sandboxes etc..

The advantage of DFS and how to set up a working structure

The advantage of DFS and how to set up a working structure

File shares are something every IT professional will work with. Many companies have way to complicated and unstructured network file systems with to deep permissions, to many shares and access points, often several connected drives and from an IT perspective nightmares when it comes to migrating to newer servers or having satellite offices and subsidiaries gaining access to it especially on lower speed connections.

Having been in IT for about 20 years by now, I saw a lot and was challenged with it quite a bit. One of the best solutions I came across is the one I am about to show you here. It is very structured while giving you the advantage of leveraging it as you need and go and should allow you to use it in most businesses.

First of all – please note that I will not go as far as explaining and exploring the differences with Active Directory integrated and Stand-A-Lone namespaces. If by any means possible, I suggest you use Active Directory integrated namespaces to simplify the roll out, but both would work.

The structure example:

The structure example will depend on a DFS Root server and a separate File-Server per root-folder on the later network drive. This is just an example, you do not need to split it all up, thought if you can do it to keep it as structured as possible

Example target file system structure:

  • N:\
    • N:\Archive
      • N:\Archive\John Doe
      • N:\Archive\Jane Doe
    • N:\Departments
      • N:\Departments\Marketing
        • General
        • Mangement
        • Public (anyone has read access)
      • N:\Departments\Accounting
        • General
        • Mangement
        • Public (anyone has read access)
    • N:\Other
      • N:\Other\Manufacturing
      • N:\Other\Projects

The declared goal is to keep the NTFS rights structure as simple as possible and not going any deeper then e.g. level three – e.g. N:\Departments\Marketing\General

Each department folder in this example will have a public folder where a member of the department has read/write access while any non-marketing member has read access to files that are published there.

The archive tree is for terminated employees and archive data. Their information gets collected in a sub-folder in this tree, a group will be created for each of those folders and only people that got approval to access this data will see and be able to read those archived files (read-only is recommended as NTFS permission)

The file servers and their preparation:

DFS Root-Server
  • create a folder on the data-partition like D:\DFSRoots – there will not be any real data in this folder – but it will hold the actual DFS structure
    • create sub folders for the branches on the shared DFS drive like:
      • D:\DFSRoots\Departments
      • D:\DFSRoots\Archive
      • D:\DFSRoots\Other
DFS Department Server
  • create a folder on the data-partition like D:\SharedFolders\Departments
    • remove the everyone or authenticated user groups from this folder – only System and Domain-Admins should have read/write permission here while group N_Departments will have read-only access on this folder.
    • create a sub-folder for each main folder you want to see under the path N:\Departments and share it 
    • add a $ (dollar/string) sign to the share name so it remains hidden a hidden share
    • Examples:
      • D:\SharedFolders\Departments\Marketing
      • D:\SharedFolders\Departments\Accounting
  • now create the following sub-folders for each department folder as shown on the example Marketing
    • D:\SharedFolders\Departments\Marketing\General
    • D:\SharedFolders\Departments\Marketing\Management
    • D:\SharedFolders\Departments\Marketing\Public
  • create two groups in Active Directory for Marketing
    • N_Departments_Marketing_General
    • N_Departments_Marketing_Management
  • create a general group N_Departments to use it for all Public folders
  • assign the groups to their according sub-folders General and Management with read/write rights you probably will need to remove the read-access that the group N_Departments inherited from this folder 
  • assign the group N_Departments to the Public folder in all departments with read-only rights (if not inherited)
  • assign the group N_Departments_Marketing_General to the Marketing\Public folder with read/write access – allowing each member of marketing to publish information for access to other people – only marketing can write in this folder, other people only have read-access to it
DFS Archive Server
  • create a folder on the data-partition like D:\SharedFolders\Archive
    • create a sub-folder for each main folder you want to see under the path N:\Archive and share it 
    • add a $ (dollar/string) sign to the share name so it remains hidden a hidden share
    • Examples:
      • D:\SharedFolders\Archive\John Doe
      • D:\SharedFolders\Archive\Jane Doe
DFS Other Server
  • create a folder on the data-partition like D:\SharedFolders\Other
    • create a sub-folder for each main folder you want to see under the path N:\Other and share it 
    • add a $ (dollar/string) sign to the share name so it remains hidden a hidden share
    • Examples:
      • D:\SharedFolders\Other\Manufacturing
      • D:\SharedFolders\Other\Projects

The DFS namespace set up and configuration

  • add the Namespace \\domain.local\N for the N: drive (just an example)
  • add the folders Archive, Departments and Other to the namespace
  • for each of those folders you add the shared sub-folders like indicated in the list below as sub-folders (they will appear on the Namespace tab when you click on the folder in the DFS Management) and set the target to the according file-share on the specific DFS server where the data will reside
    • Departments\Marketing
    • Departments\Accounting
    • Archive\John Doe
    • Archive\Jane Doe
    • Other\Manufacturing
    • Other\Projects
    • This will actually create a shared sub-folder on the DFS Root server for each of those folders in D:\DFSRoot\

Note – information about the above example

The example below is kept simple – I did not go in to each and every right you would need to assign for the sole purpose of keeping it simple and understandable. Please investigate and set the rights as you really need them. 

As for the Archive tree, it might be beneficial to have PowerShell script automate the folder creation, group creating and rights assignment for those NTFS paths, so you limit the possible failure-rate in case you are going to archive terminated employee data and other stuff in this tree branch.

What are the real benefits of this

  • add multiple folder targets for replication
    • replication can be beneficial in a server-migration scenario as well as in a subsidiary scenario
    • you can add replications on the departments-branch example per department folder – not each subsidiary will need a mirror folder of each department, rather then just a few – this decreases the amount of data and load on the connection and size of the server respective it’s disk-space and reduce cost as well
  • a simple rights structure fully based on groups
    • in general you should never ever use a user account to assign any rights – always create a group, whether for a drive-share, NTFS rights or any other purpose. Always create a group!
    • you can add and remove users from those groups
    • you can audit the permissions on the NTFS side rather quick cause they should relate to strong group names
    • the groups can be audited against HR lists of members of the department or by department managers and directors to make sure only people that need to have certain access levels will have them
  • while limiting access to certain folders you limit the amount of damage a possible attack by malware could cause 
  • you can divide or summarize the actual file-servers that hold the data as needed in the long run
  • a simple group design with limited depth permissions is easier to maintain and audit
  • you have one central network drive that you will assign in order to give everyone access – all data will be centrally on this path independent from any file-server host-name. This can be a huge advantage cause some applications might not relate to the mapped drive rather than a UNC path what could cause you major headache when ever you want to migrate/upgrade or retire your file-servers later on
  • possible other file-shares within the corporation in other locations could be made accessible by linking them in as a folder in e.g. the others-namespace avoiding that users would need to know and remember the UNC path and you even allowing them to access any UNC path – it will act like a mapped drive while pointing in the background to an UNC path

There are many more advantages to DFS and the whole design. I hope this gives you a good overview and idea of how to design or re-design your file-server structure and simplify the whole access structure. 

Full text search and DFS drive mappings

This is a challenge that is not easy to overcome. Still, thought there is no official and directly implemented solution from Microsoft for this, I was able develop and provide a solution that will access the Windows Search Index and provide it back to the end user only using standard Windows components. All you need to know and do is described in the IT Search section of this web site.

Monitoring Shadow-Copies with PRTG

Monitoring Shadow-Copies with PRTG

This was originally posted here by myself:

This is my solution for it – we monitor specific drives we enabled for shadow copy and wanted to see amount of shadows, newest should be within x hours and oldest should be at a minimum n hours – those limits can be configured with the limitations rather easily.

Main issue is – we talk about WMI modules that are only available in x64 if you use a x64 system. Now PRTG is executing sensors in x86, even thought it is installed on x64. Now, played around a while and came up with this simple solution.

Parameters for the parser-script (the one you need to execute) are: %host C: %host D: etc.

Parser script, needs to be in EXEXML directory: Name: Get-ShadowCopyStatsXMLx64parser.cmd

PS1 script, should to be in EXEXML directory – if not, adjust path in parser script: Name: Get-ShadowCopyStatsXML.ps1

PS: yes, the PS1 could be further optimized, but it took me already a while to find out the main issue was the x86/x64 combination, what is not possible – see Microsoft articles in MSDN/KB for more information while the Shadow-Copy WMI modules are only available in x64 on a x64 system.

Hope this helps others with the same challenge 🙂