ServerCore – Webbanshee

ADFS Server Core Token Signing Certificate

WebBanshee — Wed, 27 Oct 2021 10:38:03 +0000

Hi there, we have upgraded our servers. ADFS servers are running on Windows Server 2019 Core now. Therewith the method of the yearly renewal of the Token Signing Certificate has changed to PowerShell only.

I have just finished the renewal of the Token Signing Certificate via Powershell in our test environment. In this post, I will sum up the steps.

In case you want to renew the Token Signing certificate via GUI on an appropriate server see this post: Renew ADFS Token Signing Certificate

Let’s start with a short description of relevant ADFS properties: [Get-ADFSProperties | fl *cert*]

CertficateGenerationThreshold :

Has by default a value of 20 ( days ). That means that 20 days before the current primary ADFS Token Signing Certificate expires, a secondary certificate will be generated ( this will be the new cert after the current one expires ). You can check if the secondary certificate has already been created withe the following commands:

Get-AdfsCertificate -CertificateType Token-Signing
Get-AdfsCertificate -CertificateType Token-Decrypting

When the secondary certificate exists the ouput should list minimum two certificates. Focus on the certificate which has the attribute IsPrimary set to False. Verify that the Not Before: date is correct.

AutoCertificateRollover :

The default value of this attribute should be set to $True and should only be changed to $False for the time when the automatically created secondary certificate will be assigned as the primary ADFS certificate. When you manually renew the Token Signing Certificate this should always be set to $False. Otherwise, the secondary certificate will be promoted as the primary certificate automatically. Web logins to application servers will not be possible until the new certificate has not been introduced on the affected application servers.

CertificatePromotionThreshold :

This attribute is important and should be monitored before the upcoming expiration of the current ADFS Token Signing Certificate. It defines after how many days ( counting from the creation date of the secondary ADFS certificate ) the new certificate will be defined automatically as primary.
If the value of this attribute is set to 15 it means that the secondary certificate will be assigned as primary automatically after 15 days.
Based on the example above the servers should be updated with the thumbprint of the new certificate maximum of 15 days ( better earlier ) after the creation of the secondary ADFS Token Signing Certificate.

CertificateRolloverInterval :

Defines the interval in minutes at which ADFS checks if a new certificate needs to be generated. The default value is 720. If you change the values above accordingly to their meaning and your needs you can lower this value to 5 minutes for instance to generate the secondary certificate if it has not been generated yet. Set it back to default afterward.

Microsoft describes these properties here.

With that being said we are good to go. Log on to your ADFS Server Core.

Query the secondary Token Signing and Decrypting certificates

Get-AdfsCertificate -CertificateType Token-Signing | where {$_.IsPrimary -eq $False}
Get-AdfsCertificate -CertificateType Token-Decrypting | where {$_.IsPrimary -eq $False}

Note the thumbprints. You will need them later.

Export the secondary Token Signing Certificate

Export the certificate to a location you can reach from the application servers. I usually export the cert to a local folder on the ADFS server.

$certRefs=Get-AdfsCertificate -CertificateType Token-Signing | where {$_.IsPrimary -eq $False}
$certBytes=$certRefs[0].Certificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
[System.IO.File]::WriteAllBytes(“C:\PathToExportFolder\CertName.cer”, $certBytes)

Import the certificate from your ADFS Server Core to all Exchange servers

The certificate will be imported to the Trusted Root Certification Authority of LocalMachine:

Import-Certificate -FilePath \\ADFSServerName\c`$\PathToExportFolderOnADFSServer\CertName.cer -CertStoreLocation Cert:\LocalMachine\Root

You can check that the certificate has been imported successfully via remote MMC from a GUI server:

MMC > Add/Remove Snap-in > Certificates > Computername > This snap-in will manage: Another Computer > Enter the ServerName where you just have imported the certificate.

Navigate to ServerName\Trusted Root Certification Authorities > Certificates and verify that the imported ADFS Signing certificate is there.

Of course you can check it with PowerShell as well:

Set-Location -Path cert:\LocalMachine\root
Get-ChildItem | where {$_.subject -like “*ADFS*”} | fl

Promote the new secondary certificate to primary on ADFS Server Core

After this logins to web services on the involved application servers using ADFS will not be possible until the new certificate has been introduced on the application servers! ( E.g. Exchange OWA )

Set AutoCertificationRollover to False to be able to promote your secondary certificate to primary:

Set-ADFSProperties -AutoCertificateRollover $False

Query the thumbprint of the new Token Signing and Decrypting certificates:

Get-AdfsCertificate -CertificateType Token-Signing | where {$_.IsPrimary -eq $False}
Get-AdfsCertificate -CertificateType Token-Decrypting | where {$_.IsPrimary -eq $False}

Note the thumbprint of both certificates.

Promote both secondary certificates ( Token Signing and Decrypting ) to primary:

Set-AdfsCertificate -IsPrimary -CertificateType “Token-Signing” -Thumbprint ThumbprintGoesHere
Set-AdfsCertificate -IsPrimary -CertificateType “Token-Decrypting” -Thumbprint ThumbprintGoesHere

However, I got an error here stating that I need to add the certificate first. When I tried to add the Token Signing certificate on ADFS Server Core:

Add-AdfsCertificate -CertificateType Token-Signing | where {$_.IsPrimary -eq $False}

The output was a message stating the certificate is already added.

I think you need to wait a little bit after you set AutoCertificateRollover to True. Several tries later it succeeded. To be honest I could not identify the cause – I just assume it could have been the elapsed time after I set AutoCertificateRollover to True.

Verify that the new certificates have the primary status:

Get-AdfsCertificate -CertificateType Token-Signing | where {$_.IsPrimary -eq $True}
Get-AdfsCertificate -CertificateType Token-Decrypting | where {$_.IsPrimary -eq $True}

Switch AutoCertificateRollover back to True:

Set-ADFSProperties -AutoCertificateRollover $True

Check it:

Get-ADFSProperties | fl *cert*

AutoCertificateRollover should be True!

Introduce the new Token Signing Certificate to the Exchange organization

It is enough to fire the following command once from an Exchange Server within your organization:

Set-OrganizationConfig -AdfsSignCertificateThumbprint ADFSTokenSigningCertThumbprint

Verify the AdfsSignCertificateThumbprint:

Get-OrganizationConfig | select adfs*

Restart IIS:

iisreset /noforce

Or Restart IIS remotely:

invoke-command -computername “ServerName” -scriptblock {iisreset /noforce}

Now try to login via web frontend to your application servers. ( try an Outlook on the Web login )

That’s it

Stay healthy!

The post ADFS Server Core Token Signing Certificate appeared first on Webbanshee.

Add Secondary IP Address Windows Server

WebBanshee — Mon, 07 Dec 2020 11:22:19 +0000

If you want to add a secondary IP Address without using the Change Adapter Options in the GUI ( especially on Windows Core servers ) you could use sconfig or simply add the IP address with PowerShell.

In my case, I wanted to add a secondary IP address to a certain interface on some Windows Server Core servers. Unfortunately, an Invalid Index error was thrown when I chose the appropriate interface under sconfig – Network Settings:

However, I faced this error a couple of months ago already when I wanted to Disable IPv6 in my test lab.

Because this time it was production servers I didn’t want to change any settings while adding secondary IP addresses to the servers. The only option was to add a secondary IP address via PowerShell.

… and here we go:

Add Secondary IP Address to Network Interface:

List Network Interfaces with name and Interface Index

Get-NetAdapter

Display existent IPs on chosen Network Interface

To list IPv4 and IPv6 IP addresses:
Get-NetAdapter -ifIndex ifIndex Number | Get-NetIPAddress | select IPAddress | ftTo display only IPv4 addresses:
Get-NetAdapter -ifIndex ifIndex Number | Get-NetIPAddress | where {$_.AddressFamily –eq “IPv4”} | select IPAddress

Add new IP address

New-NetIPAddress –IPAddress “IpAddress goes here” –PrefixLength 24 –InterfaceIndex ifIndex Number

The command adds the IP address to the ActiveStore and the Persistent Store.
You can read more about the PolicyStore values here.

Verify that add a secondary IP address was successful

Get-NetAdapter -ifIndex ifIndex Number | Get-NetIPAddress | where {$_.AddressFamily –eq “IPv4”} | select IPAddress

Thats all. You don’t need to specify a default Gateway since this has most likely be done already with the initial IP address.

Remove IP Address from Network Interface:

List Network Interfaces with name and Interface Index

Get-NetAdapter

Display existent IP addresses that can be removed on chosen Network Interface

We focus here only on IPv4 addresses. See point above to display IPv6 as well.
Get-NetAdapter -ifIndex ifIndex Number | Get-NetIPAddress | where {$_.AddressFamily –eq “IPv4”} | select IPAddress

Copy IP address to remove from the output.

Remove IP address

Insert copied IP address in the command below:
Get-NetIPAddress –IPAddress IPAddressToRemove –InterfaceIndex ifIndex Number | Remove-NetIPAddressYou will need to confirm it for both PolicyStores.
Otherwise you could use the command with -Confirm:$false

add secondary IP address verify

Get-NetAdapter -ifIndex ifIndex Number | Get-NetIPAddress | where {$_.AddressFamily –eq “IPv4”} | select IPAddress

I have compiled the above steps in a script to make it more convenient:

Script to Add/Remove IP Address

The post Add Secondary IP Address Windows Server appeared first on Webbanshee.

Remote PowerShell Session to Server Core

WebBanshee — Tue, 22 Sep 2020 14:59:13 +0000

Hello Folks, this is just a simple post on how to open and enter a Remote PowerShell Session from one server to another. A lot of tasks on different servers can be accomplished in a convenient way from one server.

For instance if you want to Change the Keyboard Layout on the login screen of a new Server Core installation.

We will use the cmdlets below to open, enter, exit, and remove a Remote PowerShell session.

Remote PowerShell Prerequisites:

To receive PowerShell remote commands PS-Remoting must be enabled on the computer. PS-Remoting is enabled by default. Further the WinRM Service needs to be started.

If you want to go for sure firstly check the PS-Remoting state of the remote computer with:

Test-WSMan -ComputerName NameOfRemoteComputer

Afterward, verify the state of the WinRM service on the remote computer that it is running:

Get-Service WinRM -ComputerName NameOfRemoteComputer | Select MachineName,Name,Status

Remote PowerShell Session Cmdlets:

Get-PSSession – [Shows current sessions]
New-PSSession – [Create a new persistent connection to the target host]
Enter-PSSession – [Enter a session as interactive session]
Exit-PSSession – [Exit session. The session will still be alive in the background]
Disconnect-PSSession – [Disconnect from the session]
Connect-PSSession – [connect to a disconnected session]
Remove-PSSession – [Remove an earlier created persistent session]

Ok, here we go …

Create a Remote PowerShell Session with New-PSSession:

New-PSSession -Name NameOfSession -ComputerName NameOfRemoteComputer -Credential Domain\Username.

In case you don’t want to give the remote PowerShell session a name it will be named WinRM*

Check the newly created session with Get-PSSession:

Get-PSSession

The output will show the state of the session:
I gave my session the name “ServerCore”. It connects to an Exchange 2019 server running on Server 2019 Core with hostname “exchange2019”

If you have more sessions you can go for the computer name:
Get-PSSession -ComputerName NameOfRemoteComputer

… or explicit for the session name:
Get-PSSession -Name NameOfSession

… and also for the Id:
Get-PSSession -Name ID

Enter a session directly as an interactive session with Enter-PSSession:

Enter-PSSession -ComputerName NameOfRemoteComputer
Enter-PSSession -name NameOfSession.

As a result, PowerShell switches to the entered interactive session:

You can perform tasks on the target server via PowerShell from the localhost within this session now.
Enter-PSSession does not require a session that has been created with New-PSSession before.

Find more on how to run Remote Commands from a Remote PowerShell Session here.

Exit an interactive session with Exit-PSSession:

Within the remote PowerShell type:
Exit-PSSession

Instead of Exit-PSSession, you can just type Exit as well. It will have the same effect.

Thereafter, the session remains open but you have left the interactive session into the localhost’s PowerShell:

Disconnect a session with Disconnect-PSSession:

You can disconnect a remote PowerShell session which has been created with New-PSSession.
But you can’t disconnect an interactive session that has been initiated with Enter-PSSession.

To disconnect a session run the command below from your localhost’s PowerShell:

Disconnect-PSSession -name NameOfSession

…or disconnect it based on the ID:
Disconnect-PSSession -Id ID

Further, you can disconnect all remote session for a certain remote host based on ComputerName:
Disconnect-PSSession -Id ComputerName

Following you get an output like this:

You can later reconnect by using the Connect-PSSession cmdlet.

Reconnect a disconnected PowerShell session:

As shown below you can reconnect an existing session that has been created with New-PSSession:

Connect-PSSession -name NameOfSession… or you connect it with its ID:
Connect-PSSession -Id ID… as well as with ComputerName:
Connect-PSSession -Id Computername

Remote PowerShell Session to Exchange Server

To connect with a Remote PowerShell Session to Exchange use:

$UserCred = Get-Credential

$ExSession = New-PSSession -ConfigurationName Microsoft.Exchange –Name ExchangeSession -ConnectionUri “http://RemoteExchangeFQDN/powershell” -Credential $UserCred -Authentication Kerberos

Import-PSSession $ExSession

You can verify the session with name ExchangeSession you just openend with Get-PSSession:

The Exchange CMDLets will be available now.

The same can be done from an Exchange Management Shell to connect through a Remote PowerShell session to another Exchange Server:

Open an Exchange Management Shell

If you are on a Server Core type LaunchEMS into the command window.

Use the CMDlets from above

That’s all.

To display the output of a PowerShell command completely without ellipses take a look here:

Expand PowerShell Output

The post Remote PowerShell Session to Server Core appeared first on Webbanshee.

Change the Input Language on Server Core

WebBanshee — Fri, 28 Aug 2020 03:30:30 +0000

To be able to change the input language on Server Core’s Welcome Screen with ALT + SHIFT you first will need to install the the input method of your preferred language.

Open a remote Power Shell session from another server so you can log in with your preferred language layout. You can also log in directly to the server using the server core’s default language layout.

In case you log in directly type powershell into the CMD window.

Check the WinUserLanguageList for installed languages:

$UserLangList = Get-WinUserLanguageList
$UserLangList

The Get-WinUserLanguageList cmdlet returns language settings regarding input method, spelling, and text prediction. Accordingly, this example shows a Server 2019 Core with only the default language installed:

Change the input language by adding your preferred layout to the list:

You can find a list of language codes here: List of Language Codes

Find the relevant Syntax in the BCP 47 Code column.

In our example, we will add German as an additional input method.
As a result, one will be able to change the input language to German already at the login screen as well.

$UserLangList.Add(“de-DE“)
Set-WinUserLanguageList -LanguageList $UserLangList

Check the WinUserLanguageList again:

$UserLangList
The output will show the additional input language:

From this point, you will be able to change your keyboard language with ALT + SHIFT

Remove input language from the language list:

Just in case it is needed you can remove a language as follows …

First, you will need the position of the language you want to remove:

$UserLangList

Bear in mind that the first language is position 0 and hence the second language is position 1!

Remove the language by pointing to the appropriate [position number]:

$UserLangList.Remove($UserLangList[1]“)
Set-WinUserLanguageList -LanguageList $UserLangList

Verify that the language has been removed:

$UserLangList

The German input method has been removed from the WinUserLanguageList.

Enjoy your day and stay safe.

The post Change the Input Language on Server Core appeared first on Webbanshee.

Install Exchange Server 2019 on Server 2019 Core

WebBanshee — Wed, 03 Jul 2019 10:40:18 +0000

Part 5: Install Exchange Server 2019 on Server 2019 Core

1 2 3 4 5

This is Part 5 , the final part of this series. After we have checked thy system requirements and have installed the prerequisites in Part 4 we can Install Exchange Server 2019 on the prepared Server 2019 Core server.

In order to Install Exchange Server 2019 we need to copy the Exchange Server ISO file to Server 2019 Core:

Since this is a Server Core the most convenient way for me was to open an explorer and reach out to the Server Core’s drive C$. You will need to log on as a Domain Admin. ( Testlab.local )

> Copy the Exchange Server 2019 ISO file to Server Core. ( Exchange2019 )

Make sure you have read the info and you have installed all prerequisites mentioned in Exchange Server 2019 Prerequisites.

Mount the exchange Server 2019 ISO file:

The following lines describe how to mount an .iso file on Server Core.
I found the information on Mike F Roobin’s blog very clear and helpful.

Mount-DiskImage -ImagePath ‘C:\PathToYourISOFile.iso’ -StorageType ISO -PassThru

Now we need to know the assigned drive letter:

Mount-DiskImage -ImagePath ‘C:\PathToYourISOFile.iso’ -StorageType ISO -PassThru | Get-Volume

My .iso has got drive letter E:

Install Exchange Server 2019:

Prepare Active Directory for Exchange 2019:

We will need to run PrepareSchema, Prepare AD and PrepareAllDomains first. Make sure once again that the Exchange Server can reach the ActiveDirectory as a Domain Member. Use a Domain Admin Account.

PrepareSchema:

E:\Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareSchema

PrepareAD:

E:\Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD /OrganizationName:”TestLab.local”

PrepareDomains:

E:\Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAllDomains

Install Exchange 2019:

E:\Setup.exe /m:install /roles:m /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents

This can take an extended amount of time. Consider to give the VM where you install Exchange Server 2019 the most possible RAM and CPU power.

When I started to build a new test lab I had just 16GB of RAM installed on my host system. So I gave the Exchange Server 6 GB of RAM and eight I7 Skylake cores.
With these specs, it took somewhat over an hour to install Exchange 2019.

Later I extended my RAM amount to 48GB. Exchange 2019 usually gets 16GB now. That is well enough for my test lab.

Ok, there is nothing more left to be said.
Enjoy your Exchange Server 2019

The post Install Exchange Server 2019 on Server 2019 Core appeared first on Webbanshee.

Join AD Domain Server Core – Server 2019

WebBanshee — Fri, 28 Jun 2019 05:51:44 +0000

Part 3: Join AD Domain Server Core

1 2 3 4 5

This is Part 3 of how to Prepare a Hyper-V Exchange 2019 Lab and this post named Join AD Domain Server Core describes exactly what the name suggests: We will join Windows Server 2019 Core ( Exchange2019 ) to the Domain we have set up in Part 2

Join AD Domain Server Core – Join Server 2019 Core to AD domain:

Logon to Exchange2019 ( Windows Server 2019 Core ) and type:

> sconfig > Choose 1 > Choose (D)omain
> type in the name of the domain to join. In this case testlab.local.

You will need to provide the credentials of the domain admin user.

When asked if you want to rename the computer before restart do so if not already done otherwise click:

No > Restart

Your domain ( testlab.local ) should be pingable now from this server.

Manage Server Core from AD Server Manager via GUI:

Log on to AD2019 ( Windows Server 2019 Desktop Experience ) and open Server Manager
Go to:

> Dashboard > Add other servers to manage

Choose the DNS tab and write in the server name of the Exchange 2019 server ( Exchange2019 ):

> Add the server and click OK.

Exchange2019 will now appear in All Server ready to be managed with the following options to your disposal:

Before we start to install Exchange Server 2019 on Windows Server 2019 Core ( Exchange 2019 ) let’s check the system requirements and prerequisites covered in Part 4:

Exchange Server 2019 Prerequisites

The post Join AD Domain Server Core – Server 2019 appeared first on Webbanshee.

Exchange Server 2019 Hyper V Install

WebBanshee — Sat, 22 Jun 2019 06:49:49 +0000

Part 1: Exchange Server 2019 Hyper V Install – Prepare VMs

1 2 3 4 5

This post is the first part of a series where I share my experience on how to prepare an Exchange Server 2019 Hyper V install and install an AD Server and an Exchange 2019 Server on Hyper V. The first part covers the Virtual Machines.

Microsoft recommends min. 128 GB of RAM for an Exchange 2019 Install in a production environment. Curious about how Exchange 2019 behaves and for testing purpose I will set up a test environment on my test lab before we start to build our real test environment at work.

Before we begin some information on the available resources :

Processor:
I7-6700

Memory:
16GB of 2133Mhz RAM running on Windows 10 Pro 1803 ( at time of preparing the VMs and installing Exchange Server 2019.) Now upgraded to 48GB of RAM

Hyper-V Manager Build:
10.0.17134.1

Disk for Domain Controller vhdx:
7200 rpm HDD

Disk for Exchange 2019 core vhdx:
SSD Samsung Evo

You see it’s just a home lab, so much more curious am I if Exchange 2019 is able to run with these specifications.

Exchange Server 2019 Hyper V Install

Target is to prepare 2 VMs

Server 2019 as Domain Controller running Active Director with Desktop Experience ( GUI )
Server 2019 Core where we will install Exchange 2019

Ok let’s get to it :

Create a new Virtual Machine for the Domain Controller ( AD2019 ) running on Server 2019 with Desktop Experience ( GUI )

Specify Name and Location:

> Next

> Choose 2nd generation > Next

Assign Memory:

I do not use Dynamic Memory in hope of a better Performance.
When we later prepare the VM for an Exchange Server 2019 Hyper V Install a fixed memory is mandatory. Exchange 2019 does not support Dynamic Memory.

> Next

Configure Networking:

Set it to fit your needs but make sure that Exchange and the Domain Controller can communicate with each other. I will choose the default switch for both VMs. This makes sure that they NAT to the NIC of the host machine ( Win 10 ) and have internet access. You can block internet access if needed through the firewall of the host machine by blocking all inbound and outbound connections from and to the Hyper-V default IP ( 174.24.96.129 ). When blocked both guests still can communicate with each other.

> Next

Connect Virtual Hard Disk:

Under Create a virtual hard disk specify the location and size of the Virtual Disk ( .vhdx ). In this case, 45GB will be more than enough for my needs.
If you already have a Domain Controller prepared on an existing virtual hard disk choose that option.

> Next

Installations Option:

Choose the location where you have stored the Server 2019 installation media.

> Next

Check the Summary and confirm with Finish.

Go to the Settings of the newly created Virtual Machine to check the hardware :

Firmware:
Make sure you boot from your chosen Windows Server 2019 install media location.
Memory:
You can change the Amount of Memory here if needed and specify the memory weight.
Processor:
By default, your Virtual Machine has 1 processor. Change this according to your possibilities but set a minimum of 4 processors.
Integration Services:
Enabling Guest Services provides an interface for the Hyper-V host to bidirectional copy files to or from the virtual machine using the Copy-VMFile cmdlet.

Install Windows Server 2019 with Desktop Experience

First, connect to the newly created Virtual Machine ( Ad2019 ). It is easier to hit a key straight away after the VM starts when you connect first. You will need to hit a key to boot from DVD.

> Now press Start and press a key to boot from DVD.

Set the language to install, Time and currency format and the keyboard or input method.

> Next > Install Now > Type in the product key or activate your copy later > Next

This VM ( AD2019 ) will run Windows Server 2019 Datacenter Edition with Desktop Experience.

> Next > Accept license terms > Next

Since this scenario covers a new install on a new VM choose Custom

> Select the drive for the install. You can create an additional partition as well. > Next

Wait until Windows Setup finishes. Depending on your chosen hardware specs this can take some time.

> Specify a password for the built-in administrator account to sign in on this computer > Finish

Create the 2nd Virtual Machine for Exchange 2019 running on Server 2019 core.

In Hyper V Manager create a new virtual machine and repeat the steps listed under Point 1.

> Note: Do not store both VMs on the same disk. ( Performance ) and don’t use Dynamic Memory ( Exchange 2019 requires fixed memory )

I gave this VM 60 GB disk space. This should fit all needs for this Exchange Server 2019 Hyper V Install.

Don’t forget to adjust the hardware in the settings of the VM.

Install Windows Server 2019 core on the 2nd Virtual Machine

Again first connect to the newly created Virtual Machine ( Exchange2019 )

> Press Start and hit a key to boot from DVD.

Set the language to install, Time and currency format and the keyboard or input method.

> Next > Install Now > Type in the product key or activate your copy later > Next

This VM ( Exchange2019 ) will run Windows Server 2019 Datacenter Core named just Windows Server 2019.

> Next > Accept license terms > Next

Since this scenario covers a new install on a new VM choose Custom

> Select the drive for the install. You can create an additional partition as well. > Next

Again wait until Windows Setup finishes. Depending on your chosen hardware specs this can take some time. The install to the SSD is really fast and takes only a couple of minutes.

After the install has finished you need to change the password of the built-in Administrator

Now we need to make sure that both servers can communicate with each other:
Disable IPV6 on the Domain Controller ( AD2019). Otherwise, the server responds with its IPV6 IP. For me, it is more transparent this way since my config is based on IPV4.

You can disable IPV6 on Server Core ( Exchange 2019 ) as well if needed.
After I have disabled IPV6 on Server 2019 Core I was not able to open Network Settings under Network Adapter Settings: Invalid Index.

Find more information here :
Disable IPv6 on Server Core through Powershell and deal with the Invalid Index state

Next, disable the appropriate Firewall to make sure both servers can see each other:

Note: Since it is a test lab I have disabled the firewall on all three networks > Domain, Public and Private. Adjust this according to your environment.

Disable Firewall on Exchange2019 Server Core and enable Remote Management:

Check the status with:

Get-NetFirewallProfile | select name, enabled

Disable the firewall:

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled false

The core server Exchange2019 will be pingable now.

Enable Remote Management: Powershell

Configure-SMRemoting.exe –Enable

Configure a network interface to communicate with the Domain Controller:

Type sconfig > the Server Configuration shows up.

> Choose number 8 – Network Setting and choose the Network Adapter:

I have already assigned a fix IP address to this server.
You can configure the IP address and Default Gateway through the following options:
Set Network Adapter Address :

> Select S for Static > Enter Static IP address > Subnet mask 255.255.240.0

I use the Hyper V defaults here

Enter the Default Gateway:

Hyper V default switch IP Address: 172.24.96.129

Set DNS Server:

> Type here the IP Address of the Domain Controller ( AD2019 ).

Now that both servers can ping each other the next step in our Exchange Server 2019 Hyper V Install will be to prepare and install the AD Server Role on Server 2019 Desktop Experience.

This is covered in Part 2 : Install the Active Directory Role on Server 2019

The post Exchange Server 2019 Hyper V Install appeared first on Webbanshee.

Disable IPv6 on Server Core with Powershell

WebBanshee — Sat, 04 May 2019 15:49:36 +0000

For whatever reason you may need to disable IPv6 on Server Core or any other server sometimes.

When I was building my new test lab I wanted all servers to communicate and respond to ping only in IPv4. So I started to disable IPv6 on Server Core via Powershell.

After this the server responded to ping with its IPv4 address but SCONFIG > Network Settings > Network Adapter Settings showed an Invalid Index.

The solution for me was to enable IPv6 on Server Core again. The server still responds in IPv4 and the Network Adapter Settings are available again.

Here are the steps …

Disable IPV6 on Server Core via Powershell:

Switch to Powershell by typing powershell

Check the current status of the Adapter Bindings:

Get-NetAdapterBinding -ComponentID ‘ms_tcpip6’

Disable IPV6:

Get-NetAdapterBinding -ComponentID ‘ms_tcpip6’ | Disable-NetAdapterBinding -ComponentID ‘ms_tcpip6’ -PassThru

It is possible that Network Settings > Network Adapter Settings >with SCONFIG will show an invalid index after this:

One answer from a technet forum goes as follows:

( sorry, I just copied the text but do not have the referencing link anymore )

Based on my research, this is a known issue when IPV6 is disabled, we first need IPV6 enabled when configuring an IP address using SCONFIG. Once the IP Address is assigned, you can disable IPV6 afterwords.

This was what did not work for me After the IPv4 address was assigned and IPv6 was disabled the server was reachable and responded but the Network Adapter Settings still came with an Invalid Index.
So I enabled IPv6 again and left it this way. Everything works fine until now, the server responds with its IPv4 address.

Enjoy the spring!

Add Remove IP addresses despite the Invalid Index error:
Add IP Address Windows Server

The post Disable IPv6 on Server Core with Powershell appeared first on Webbanshee.