I've successfully installed Windows Server 2019. I've installed the following Roles: ADDS, DHCP, WDS. Active directory works fine, dhcp work proper. WDS when i try to open the WDS manager will freeze. I've installed in multiple system so it's not a problem with my VMWare Workstation 14. Also i've tried both versions. Standard and Data Center.

Second glitch it's the network settings. When you right click on ethernet icon and try to go to advance option. On the left panel click Ethernet and first option it's to change Adapter option. You will get an error which said that you don't have enough rights to do that. I've created a new user with Domain Admin, Enterprise Admin, Administrators groups yet no success. So the single way to change the ip address on the adapter you have to go to advance option and get back into the ethernet icon.

IIS services will not detect your website if you haven't created before the A record or CN in DNS. So you have to create it it first in DNS the name of the record.

Sometimes the dashboard will not close just hang in there. I assigned to my Server 16 Cores and 12 GB of RAM so i don't think it's a problem with my spec.

After installation of AD DS and automatically restart will occur when the Windows it's loading back it's take at least 10 minute to set up the new settings of AD DS.

Hope this will help in solving this Issues

I am a microsoft trainer for about 8 years so i think its important for you to hear my suggestions about windows server 2016 (the latest update).
Win server 2016 has so many bugs and you are losing your customers.
Everyone tells me that master please dont tell me about winserver 2016 any more its not reliable and has so many issues.
So if you as microsoft server team want to know about all of the problems please send me an email so i will tell you all about the problems that im sure you dont know aboute all of them.
Thaks
Mahyar safaei

If a Powershell script creates a DFSR RG and invokes the CmdLet "Set-DfsrMembership" multiple times to add several member servers then there is a high probability that the CmdLet will fail.
I have a PowerShell script than creates a new DFSR RG, adds the local server and a folder, then calls the above CmdLet.
if the script is run in a loop (deleting the RG between iterations) then the script will fail after 2 - 5 loops.

I've used .NET Reflector to debug the DfsrPowershell, DfsObjectModel and DfsrHelper DLL's and I found that the error is as follows:
Set-DfsrManagement attempts to modify the Replication Group object under the target computer in Active Directory. It first attempts to perform the operation using the currently logged on user's credential and when that fails it retries using using the target computer account. This normally succeeds however, when it does fail the LDAP response is invalidAttributeSyntax
Examining the modifyRequest command I see one of the attributes is:
modification item operation: delete (1)
modification msDFSR-DfsLinkTarget
type: msDFSR-DfsLinkTarget
vals: 1 item
AttributeValue:
And the AttributeValue is empty - which is invalid!
Now the modifyRequest that was sent using the logged on user's credentials is correct:
modification msDFSR-DfsLinkTarget
type: msDFSR-DfsLinkTarget
vals: 0 items
The difference is the first modifyCommand is built and sent by the DfsObjectModel DLL while the failing command is sent by the DfsHelper DLL which is native code and described in the MS-DSFRH document.
I have debugged the code as far as the interface into DfsrHelper and confirmed that the attributes passed into the DLL are correct i.e. the msDFSR-DfsLinkTarget attribute operation is "delete" and there are no values set. Therefore I am of the opinion that there is a defect in the DfsrHelper DLL implementation that incorrectly appends an empty value when constructing the LDAP command.
I opened a MSDN case with the breakfix group who confirmed it was a bug but were unable (due to internal policy??) to submit their findings to the DFSR dev team.

In a certain powershell script i'm working on i get the following error when i try and debug:

E:\logs\Invoke-IISGraphInteractive_V1_4.ps1 :
Exception : System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: length
at Microsoft.VisualStudio.Text.Span..ctor(Int32 start, Int32 length)
at Microsoft.PowerShell.Host.ISE.ISEEditor.MarkPosition(Int32 lineNumber, Int32 startPosition, Int32
endPosition, String marking)
at Microsoft.PowerShell.Host.ISE.ISEFile.SetDebuggerCurrentPosition(Int32 lineNumber, Int32
startColumn, Int32 endColumn)
at Microsoft.PowerShell.Host.ISE.PowerShellTab.DoEnterDebugger()
at Microsoft.PowerShell.Host.ISE.PowerShellTab.DoEnterNestedPrompt(Object context)
at
Microsoft.Windows.PowerShell.Gui.Internal.WPFHelper.<>c__DisplayClass9.<SendToUIThread>b__8(Object obj)
TargetObject :
CategoryInfo : OperationStopped: (:) [Write-IISResponseCharts], ArgumentOutOfRangeException
FullyQualifiedErrorId : System.ArgumentOutOfRangeException,Write-IISResponseCharts

here is the code block:

$DataToUse = $data.data |Where {$_['time']}| where $CoreFilterSB | where $FilterSB
$TransformedData = $DataToUse |
select @{n='Series';e={Invoke-Command $seriesSB -ArgumentList $_}},
@{n='Time-taken';e={
[int]$TimeSec = [Math]::Round(([double]($_['time-taken'])/1000.),0)
if ($HistogramLogScale)
{
if ($TimeSec -eq 0)
{
0
}
else
{
#round down the call time as a log base 2, then re-raise so get original scale but bucket by powers of 2
#e.g. 0.5,3,5,6,8 --> 1,4,8
([math]::Pow(2,[math]::Floor([math]::Log($TimeSec,2))))
}
} else {
$TimeSec
}
}}
$DataArray = $TransformedData |
Group-Object Series,Time-Taken |
select @{n='Series';e={$_.Group.Series | select -first 1}},
@{n='time-taken';e={$_.Group.'time-taken' | select -first 1}},
@{n='Count';e={$_.Group.Count}} | Sort Series,'time-taken'

it crashes when i put the break point on $TransformedData = ... line

Name Value
---- -----
PSVersion 4.0
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
CLRVersion 4.0.30319.42000
BuildVersion 6.3.9600.18773
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion 2.2

Hello, after applying the below listed patches this past Sunday on Windows Server 2016 dedicated to File / Print services, searching for files on Windows Server 2016 results in the search that appears to be searching but unable to display properly.

If possible I'll send a picture comparing Windows Explorer search results from both Win10 & Win7 (both systems are up to date with latest patches, though the same view from Win 10 happens on Win 2016), a description of what I'm seeing can be described as follows:

Win 10 / 2016; you see the file name only, the rest of the search area is blank (normally it shows content and meta-data) and unlike before, right click doesn't bring up any menu options (such as opening the folder the file is saved in);
Win 7; you see blank lines, as if the fonts were white on white background, so it appears to bringing up similar results as the Win 10, but you only see the light grey line separating each search result;
Running the same search from both client machines on a Windows 2008 older file server (is also up to date on patches) shows the expected results (File name, content below file name, Meta data on the right), which is what I was seeing last week on the Win 2016 server / before applying the patches.
Look forward to feedback and confirmation if there's something else that needs to be enabled on the 2016 file print server.

Thank you,

Updates Applied on Sunday, March 4th:

Update for Windows Defender antimalware platform - KB4052623 (Version 4.12.17007.18022)
2018-02 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4074590).
Windows Malicious Software Removal Tool x64 - February 2018 (KB890830)

If have some issues with Dism after a new Installation with Windows 10 1709 and Upgrade from Windows 1703 to 1709.

Get-WindowsCapability : Error "Get-WindowsCapability". Errorcode: 0x800f0954
Line:1 Zeichen:1
+ Get-WindowsCapability -online
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-WindowsCapability], COMException
+ FullyQualifiedErrorId : Microsoft.Dism.Commands.GetWindowsCapabilityCommand

Some Lines from Dism Logfile:

DISM OS Provider: PID=7180 TID=6088 Unable to set the DLL search path to the servicing stack folder. C:\Windows may not point to a valid Windows folder. - CDISMOSServiceManager::Final_OnConnect

DISM Provider Store: PID=7180 TID=6088 Failed to load the provider: C:\Users\ADMIN~1.TES\AppData\Local\Temp\38977CD8-C67C-463B-8721-E72E5E46A990\PEProvider.dll. - CDISMProviderStore::Internal_GetProvider(hr:0x8007007e)

DISM Provider Store: PID=7180 TID=6088 Failed to get and initialize the PE Provider. Continuing by assuming that it is not a WinPE image. - CDISMProviderStore::Final_OnConnect

2017-10-19 17:39:03, Error DISM DISM Package Manager: PID=7180 TID=6088 Failed enumerating capabilities - CDISMPackageManager::GetCapabilityCollection(hr:0x800f0954)
2017-10-19 17:39:03, Error DISM DISM Package Manager: PID=7180 TID=6088 Failed to get capability collection. - CPackageManagerCLIHandler::ProcessCmdLine_GetCapabilities(hr:0x800f0954)
2017-10-19 17:39:03, Error DISM DISM Package Manager: PID=7180 TID=6088 Failed while processing command get-capabilities. - CPackageManagerCLIHandler::ExecuteCmdLine(hr:0x800f0954)
2017-10-19 17:39:03, Info DISM DISM Package Manager: PID=7180 TID=6088 Further logs for online package and feature related operations can be found at %WINDIR%\logs\CBS\cbs.log - CPackageManagerCLIHandler::ExecuteCmdLine
2017-10-19 17:39:03, Error DISM DISM.EXE: DISM Package Manager processed the command line but failed. HRESULT=800F0954

Thanks

Whilst working through some of the DNS records for our network, we noticed we were seeing some records from 2015. We tried to sort the 'Date' column in ascending/descending order and found that the fields were not formatted as 'Date/Time' but rather as a text format as the timestamps were sorted in ascending order of the first 2 numbers of the date.
As an example:
Timestamp 1: 05/04/2015
Timestamp 2: 01/02/2017
Timestamp 3: 15/03/2016
Timestamp 4: 19/06/2015

When sorted in ascending order by timestamp, the DNS records SHOULD be organised in the following format:
1: 05/04/2015
2: 19/06/2015
3: 15/03/2016
4: 01/02/2017

However, they are sorted thus:
1: 01/02/2017
2: 05/04/2015
3: 05/03/2016
4: 19/06/2015

We took a look at one of our 2008 servers and found this was the case there also.

I have been redirected here by recommendation of MSFT CSG in response to post on the Windows Server forum here: https://social.technet.microsoft.com/Forums/windowsserver/en-US/4d27b27b-5354-413f-8eeb-48ae9fb1e795/ntfs-rights-unc-vs-mapped-explorer-vs-command-prompt?forum=winserverfiles. Apparently, my question has exceeded the limits of "how do I do this?" and entered the realm of "why does Windows behave inconsistently?", which I call a bug.

Scope
The behavior below is the same for at least Server 2008 R2 & 2012 R2, both with Windows 7 workstation. I have not tested elsewhere.

Scenario
User has only traverse & permissions NTFS rights at root of share but full share-level permissions. User has full access to a subfolder of that folder. I set traverse-only at the parent level because:
1. I do not want users to be able to browse to the parent folder, even if they know the share name. Instead, I provide explicit shortcuts to applications in downline folders where users have read/write access.
2. There there is no need to disable inheritance for downline folders. I can make all rights additive at those lower levels. Since the only NTFS rights to the parent folder (which will be the root of a share) are traverse/permissions rights, and these will be required by anyone also need read/write to downline folders. I can just add read or read/write NTFS rights to downline folders by group.

Symptoms
The user can edit/copy/create/delete files from that full-rights subfolder when accessing it via its UNC path; however, when mapping a drive to the parent folder where the user's rights are traverse/permissions only, the user can still edit files in that subfolder but not create, copy from/to or delete from the subfolder via Windows Explorer; the user gets a "[DriveLetter] invalid/inaccessible" message. However, the user can create and delete files from the subfolder via command prompt, so we know the issue is not NTFS rights, but apparently the fact that Windows denies rights to create/delete/move files to/from the subfolder based on the rights at the parent level.

Here is how to duplicate

Setup
1. Create folder "Test" on any domain-member server.
2. Ensure "Everyone" group has either no rights, or at least only these rights, to "Test" folder: Traverse folder / execute file, Read attributes, Read extended attributes, and Read permissions
3. Assign Authenticated Users these rights to the "Test" folder: Traverse folder / execute file, Read attributes, Read extended attributes, and Read permissions
4. Create a subfolder like this: "Test\SubTest"
5. Assign Authenticated Users full rights to the "SubTest" folder only (not the "Test" parent)
6. Share "Test" folder as "TestShare" (the name is not important; I use TestShare here only to differentiate it from the actual folder name "Test")
7. Give Everyone share permissions Change and Read.
8. From a workstation, log on as a member of Domain Users that is NOT in Domain Admins or any other group having elevated rights to the Test folder (or downline) on the server housing the TestShare.
Test
1. Open Windows Explorer and paste this into address bar, using your own server name: \\[ServerName]\TestShare\SubTest. (Can also just do Window-R and paste that UNC path into run window, then press Enter).
2. This should open [ServerName]\TestShare\SubTest.
3. Copy a text file from the workstation (Copy/Paste or drag-and drop) to that folder. This should succeed.
4. Now map any drive letter to \\[ServerName]\TestShare, either by net use or right-click Computer/Network & Map Network Drive.
5. After the map completes, it will (correctly) generate an error indicating the driver letter is invalid. This is only because, once the drive is mapped, Windows Explorer then attempts to display the root, but the user has only the traverse-related rights above to the root. So ignore this error.
6. Instead, open Windows Explorer and paste this into address bar, using the driver letter just assigned: \\[DriveLetter]\SubTest.
7. This should open \\[DriveLetter]\SubTest, where you should see the first file you copied there previously.
8. Now try copying another file from the local computer to that subfolder. It should fail saying that [DriverLetter is invalid].
9. However, open the text file previously copied, make a change and save it, then re-open. You can see that you can change the file.
10.Open command prompt. Change to [DriveLetter], then dir to \SubTest. Enter dir > dri.txt. The text file is correctly created. Then del dir.txt. The text file is deleted. So the user retains full NTFS rights to the subfolder; it is only in the Windows Explorer environment that the user cannot copy to the subfolder when the parent is a drive letter instead of UNC path.

Further test
But now do this: map any drive letter to \\[ServerName]\TestShare\SubTest, either by net use or right-click Computer/Network & Map Network Drive. This should succeed. You can now copy files to/from the same folder via mapped drive--as long as the root of the mapped drive is an upline folder having at least List Folder Contents.

Conclusion:
1. You can copy to (or create in or delete from) the subfolder when accessing it via its UNC path, even when the user is invoking traverse-only rights at some higher level to get to the folder
2. This also works if you map the drive directly to the subfolder having full rights, even though this also invokes traverse-only rights to get to the folder.
3. This does not work if the mapped drive letter points to the traverse-only folder itself, even though all the same NTFS rights exist identically throughout all three scenarios and even though the user can open and edit files inside the subfolder when mapped this way.
Change required
Do not limit create/delete/move access within Windows Explorer by parent folder rights when user has additive rights to the subfolder.

Here's an odd one.

Promote Windows Server 2016 to a domain controller.

Using Group Policy Management, edit the Default Domain Controllers Policy as follows:

Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies - Security Options - Network security: Configure encryption types allowed for Kerberos

Choose
AES128_HMAC_SHA1
AES256_HMAC_SHA1
Future encryption types

Restart your domain controller.

Using Group Policy Management, edit the Default Domain Controllers Policy as follows:

Computer Configuration - Policies - Windows Settings - Security Settings

Notice that an IP Security Policy Management error appears.

A directory service error has occurred - (80072095)

Also notice that no "IP Security Policies" can be created, under "Security Settings".

This must be a bug, right?

If you add RC4_HMAC_MD5 as a Kerberos encryption type, the error goes away and everything works.

Using MD5 is not recommended, of course, so bascially you can't define Kerberos encryption types?

Thank you.