Some versions of Windows 2016 have an authentication issue which causes shares to not work via hostname. Shares continue to work via IP, but a registry change must be made for the share to work via hostname. You should first verify that you are definitely not experiencing a DNS issue or a cached credential issue; most of the time, it is a DNS issue.
At least one other post reports similar issues in Windows 10. When this issue arises, a dialog box prompting for credentials will pop-up, but any network credentials will return “Access is denied” and ask you to enter credentials again. The only credentials that will work are local accounts on the server.
Conditions for the Issue
Windows Server 2016 Version 1607
SmbServerNameHardeningLevel: 1 or 2
You can check the second two items by running the below command from PowerShell.
The shares do not work via hostname because of a Kerberos authentication issue. IP shares still work because it uses NTLM authentication, whereas FQDN hostname shares use Kerberos. The latest hotfixes have fixed this in most versions of Windows 10 and 2016. However, in Version 1607, it has not been addressed yet by the 2017-08 Update (KB4035631) or Security Update (KB4034658).
We discovered this by poring over many traces and logs while trying to access the shares. A packet analysis shows “STATUS_ACCESS_DENIED” replies to the Session Setup Requests from the Client. An SRV trace reveals an “SPN (cifs/SERVER.DOMAIN.com) is invalid” error.
A handful of users have encountered an issue with some or all of their Windows 10 Apps not working after an update. For myself, I noticed this happen when I tried to open my Calculator and Store apps. According to the Programount blog, this often happens if you have your display scale above 100% or multiple languages installed. In my case, I have multiple languages.
To fix my Windows 10 Apps not working, I had to try (and fail) reinstalling them using the PowerShell commands, then go digging in the Event Viewer for the specific cause of the issue. Below are the steps I followed to repair my Store App.
Open a PowerShell window; be sure to Run as Administrator…
Search for the App by Name using the following command:
Get-AppxPackage -Name <em>store</em>
Note the PackageFullName. In this example it is Microsoft.WindowsStore_11602.1.26.0_x64__8wekyb3d8bbwe.
Try to reinstall the package, and you’ll most likely receive an error:
Now we’ll have to open up Event Viewer and navigate to the below log and look for the most recent Warning message, and click on the Details tab to identify what is causing the issue. For me the issue was that a file under the ManifestPath was not found, because it did not exist–the file C:\ProgramData\Microsoft\Windows\AppRepository\Microsoft.WindowsStore_11602.1.26.0_neutral_split.language-zh-hans_8wekyb3d8bbwe.xml.
Application and Services Logs
Navigate to the folder causing the issue. If you do not have permissions to AppRepository, you will have to temporarily make yourself an Owner.
Once you are, you will probably see that the file in the ManifestPath earlier does not exist. Find a similar file and copy and paste it into the folder. I used the Microsoft.WindowsStore_11602.1.26.0_neutral_split.scale-100_8wekyb3d8bbwe.xml file.
Rename it to match the missing file from earlier.
Edit the ResourceId in the XML file to match the missing item. For me, it was split.language-zh-hans.
Revert the AppRepository folder’s Owner to NT SERVICE\TrustedInstaller.
Run the PowerShell command again, and it should run without an error
Because the Windows 10 Apps may not be working for a number of reasons, this may not solve all the Windows 10 Apps not working issues people are facing, but hopefully it can help some individuals. Regardless, let me know if you have any improvements or insights.
When you are installing or reinstalling Windows Server Update Services on a Windows Server 2012 machine, the WSUS post-deployment configuration tasks will sometimes fail.
Check the logs in C:\User\<username>\AppData\Temp\, and if the last line before the WSUS configuration failure states: “System.Data.SqlClient.SqlException (0x80131904): Changes to the state or options of database ‘SUSDB’ cannot be made at this time. The database is in single-user mode, and a user is currently connected to it. ALTER DATABASE statement failed” then you should prepare to remove the WSUS role, its associated features, and the database. Of course, you should backup your previous database, especially if this is a machine in production.
This is a snippet of the error that I kept getting in my logs:
2015-05-26 21:17:16 Configuring WID database...
2015-05-26 21:17:16 Configuring the database...
2015-05-26 21:17:19 Establishing DB connection...
2015-05-26 21:17:20 Checking to see if database exists...
2015-05-26 21:17:29 Database exists
2015-05-26 21:17:29 Switching database to single user mode...
2015-05-26 21:17:40 System.Data.SqlClient.SqlException (0x80131904): Changes to the state or options of database 'SUSDB' cannot be made at this time. The database is in single-user mode, and a user is currently connected to it.
ALTER DATABASE statement failed.
at Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e)
at Microsoft.UpdateServices.Administration.PostInstall.Execute(String arguments)
Fatal Error: Changes to the state or options of database 'SUSDB' cannot be made at this time. The database is in single-user mode, and a user is currently connected to it.
ALTER DATABASE statement failed.
1. Remove Windows Server Update Services
You will need to remove Windows Server Update Services, WID Database, and WSUS Services from the Server Roles. You will also need to remove the Windows Internal Database from the Features.
2. Delete the C:\Windows\WID folder
Unfortunately, removing the Windows Internal Database feature does not remove the actual database. You should back up this database if necessary, then delete the C:\Windows\WID folder
3. Re-install WSUS Role using a Local Admin account
Some have had success reinstalling it as a Domain Admin, however I have had mixed results. But I have never had an issue installing WSUS using a Local Admin account, so I recommend it to anyone who is still having issues installing WSUS and getting through the post-deployment configuration.
Let me know if this works for you or if you run into any other issues with your WSUS deployment.
Adding Multiple Users to Active Directory can be done very simply by creating a CSV file, which administrators can easily edit using Excel, and running the PowerShell script below. (CSV template and script download at the bottom) Someone will still have to fill out every user’s information and ensure that the proper OU exists, but after that it is smooth sailing. This is just a starting point for administrators though; it is easy to specify more categories such as Department, Telephone, E-mail, etc. by adding columns to the CSV and lines to the PowerShell script.
This CSV (download) is a starter template for adding multiple users to Active Directory. If you need to add more AD attributes, simply create a column, note the Ldap-Display-Name, and add the details for each user. Once this is complete, save it to a directory on a Domain Controller, and get ready to run the script below. We used the directory C:\ADtest in our example.
The PowerShell script
The PowerShell script (download) has been written to with the CSV template above, but administrators will still need to make at least 1 edit to the script—in Line 4, administrators will need to edit “pandatech.co” to be there domain, such as “contoso.net”. Be sure to keep the quotation marks around the domain, otherwise you will run into syntax errors. The script also assumes that you saved the CSV file to C:\ADtest. Administrators can change this -Path to existing location in Line 2.
The above shows the results from running it in PowerShell ISE. If you don’t want it to display successful results when adding multiple users to Active Directory, delete -PassThru from Line 17. If the user already exists, an error will be displayed, but the script will continue to process other users contained in the CSV. If you added more columns and attributes in the CSV, you’ll have to include the Ldap-Display-Name and column name between Lines 7-17.
This will help you configure Windows Firewall to enable remote disk management on Windows Server 2012 core installations.
Enable Firewall Exceptions on the Client and Server
You will need to enable the exceptions on both the machine you are trying to access (the Server) and the machine you are accessing from (the Client). You can do so with the following command in an elevated Command Prompt or PowerShell:
netsh advfirewall firewall set rule group="Remote Volume Management" new enable=yes
Note: My client machine updated 6 rules, but my server only updated 3 rules (as seen in the next screenshot.
On the Server, you can check if all the appropriate exceptions are enabled with the following PowerShell command:
Make sure that all three items are enabled (True). If they are not, try running the netsh command again. Also, make sure that the VDS service is running on the Server. It is also a good idea to set the VDS service to start automatically.
You can also try the commands recommended by Microsoft. They do the same thing as the netsh command above. If you want to see the individual exceptions that are updated, you can run it with the -verbose flag as I did in the screenshot.
I’ve had to use this numerous times to download either anti-malware software or a different, non-Internet Explorer browser. However, on occasion, the PowerShell’s execution policy may be set to restricted, then users will have to run this cmdlet before they can download a file using PowerShell:
Every IT technician has run into a situation where they no longer have Local Admin access to a workstation. When it happens, you’ll rarely have a Windows CD nearby to reset the password. That’s where the Offline Windows Password and Registry Editor comes to save the day.
A good technician should never show up on-site without this package in their toolbox. Just download the package, copy it to a USB, and boot from the USB. A copy of the tool is hosted on our site. The original instructions are below:
Get the machine to boot from the CD or USB drive.
Load drivers (usually automatic, but possible to run manual select)
Disk select, tell which disk contains the Windows system. Optionally you will have to load drivers.
PATH select, where on the disk is the system? (now usually automatic)
File select, which parts of registry to load, based on what you want to do.
Password reset or other registry edit.
Write back to disk (you will be asked)
Users should first review the documentation and FAQ before using this tool, but this is the easiest tool we’ve found in our experience. It is also available on CD, for anyone who may not have the option of booting from a USB.