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.
The company has moved from an on-premise Exchange Server to Office 365. You have set up AD Connect to sync all your data and passwords. You have decommissioned and uninstalled all local instances of Exchange Server. Suddenly you discover that you must manage Office 365 via Active Directory, and it seems impossible to because many settings must be changed in the Active Directory Users and Computers Attribute Editor.
Your options for management are essentially the following:
Install Exchange Server locally – Your data will be in sync. You can set up Mail-Enabled Users to manage users with mailboxes, and groups and contacts will be managed the same way as before via the Exchange Management Console.
Manage mailboxes through Active Directory Users and Computers – Your data will be in sync, and you will have the turn on “Advanced Features” to access the Attribute Editor.
This is a reference table with examples choose Option 3, and manage Office 365 via Active Directory.
When deploying your first Windows Server Core installation, you may find yourself having difficulty managing the server using Windows RSAT. This may be because there is no DOMAIN and one or both the server and workstation are part of a WORKGROUP. Below is the method I use to ensure initial access from a workstation using Windows RSAT Tools.
Firewall rules have been configured. If you are just testing, you can easily turn of the firewall by running the following:
netsh advfirewall set allprofiles state off
You’ll need to start by opening the Component Services MMC, or Run… dcomcnfg. Expand Component Services, then Computers.
Right-click My Computer and select Properties
Select the COM Security tab
Under the Access Permissions section, click Edit Limits…
Highlight ANONYMOUS LOGIN
Check the box next to Remote Access; by default it should be unchecked
Next, you’ll want to run PowerShell as an Administrator. The name of my lab server is “2012CORE” and the user is “2012CORE\Administrator“. You’ll want to replace these with your own values.
The first line will add credentials for your server to Windows Credential Manager. The second line adds your server’s DNS hostname to the TrustedHosts list. You cannot use an IP for this. If your workstation cannot reach the server via hostname, you may need to update the hosts file manually. Finally, the third line is used to verify that your server now appears in the TrustedHosts list.
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.
The more we rely on email, the more susceptible we are to spam and phishing attempts by cyber frauders. Recently, yet another company lost 3.8 million when they made a bank transfer requested by a spoofed email. How did it happen?
The attackers set up an email account that mirrored [Alutiiq CEO] Hambright’s email address and sent an email to Alutiiq’s controller that gave instructions about a “confidential transaction” by a person who called minutes later.
Pretending to be an attorney, the co-conspirator requested an “urgent” transfer of the $3.8 million “to an entity later revealed to be a fictitious third party company based in Hong Kong,” Hambright wrote. Hambright and the chief financial officer discovered the transfer two days later.
All companies small and large are susceptible to scams like this. Fortunately for Office 365 users, there is an easy way to effectively block spam and spoofing attempts by blocking senders from “Outside the organization”. Microsoft TechNet Blogger Caltaru Mihai also mentions this technique near the end of his Block Spoofing in Office 365 post and appropriately cautions “that this is a dangerous rule if not configured correctly, but it is very effective at blocking spoofing“.
Office 365 Exchange Admin Center
Log into your Office 365 Exchange Admin Center
Navigate to mailflow, then rules, and add a new rule
Click “More Options…” near the bottom of the new window
Add two conditions:
The sender’s domain is… yourdomain.com AND The sender is located… Outside the organization
Add one action:
Reject the message with the explanation… Message has been blocked as an email spoofing attempt.
Modify the message properties… Set the spam confidence level (SCL) to… 9
Add an exception(s)
This is not necessary, but it is usually a good idea to whitelist your company’s WAN IPs as well as any other legitimate services that may be sending emails on your company’s behalf. If you have SPF set up, then you can use the same IPs listed in the SPF TXT record
Let me know if this rule works out for your organization, or if you find some new ways to improve it!
Azure AD is a great new subscription based product from Microsoft, perfect for Apps and Cloud Backups, however adding a custom domain and configuring it for single sign-on with you local Active Directory can be tricky. After deleting my custom domain twice and all my synced users once, we discovered this to be the easiest way to setup single sign-on in Azure.
Active Directory Federation Services must be installed and configured
A Global Administrator on Azure Active Directory
A Enterprise Administrator on your domain
Add the domain to Azure Active Directory. Check the “I plan to configure this domain for single sign-on with my local Active Directory.”
Add a User. The user will be a “New user in your organization” and must have Global Administrator priveleges. We created “[email protected]“
Sign in with the new user and update the password.
Get the code for verifying the custom domain by opening an elevated PowerShell session and running the following commands:
Run Azure AD Connect using the Express Settings, and sign in with the account you created in Step 3 on the first page. Sign in with an Enterprise Administrator on your domain in the second page. Check “Start the synchronization process as soon as the configuration completes”, and click Install.
Installation should complete within a few minutes. The sync will automatically begin afterwards, and it may take some time depending on the size of your domain and your internet speed.
Verify that accounts appear in Azure AD afterwards, and try signing into the Azure Portal with one of your local accounts.
Hopefully this helps you configure single sign-on in Azure with your local Active Directory. Post any questions in the comments. You may also find Microsoft’s Azure AD Directory Integration documentation helpful as well.
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: