SCCM Lab: Part 2 – DHCP and DNS Server roles on our AD controller

frank August 30, 2019

This part in the SCCM Lab series will cover installing and configuring the DHCP and DNS Server roles on our headless Windows 2019 server we configured in Part 1. Here we go.

The DNS server was created when AD DS role installed the root forest. We can see that the DNS role is installed using the Get-WindowsFeature command:

Get-WindowsFeature -name "DNS*

As you can see, the DNS Server feature is installed – BUT If your DNS server is not installed, you can install it with this command:

Install-WindowsFeature DNS -IncludeManagementTools

The DNS primary zone is created when the forest is generated. Next, the network ID and file entry is made:

Add-DnsServerPrimaryZone -NetworkID 10.0.1.0/24 -ZoneFile “10.0.1.2.in-addr.arpa.dns”

Next, the forwarder is added:

Add-DnsServerForwarder -IPAddress 8.8.8.8 -PassThru

You should now be able to test your dns server:

Test-DnsServer -IPAddress 10.0.1.2 -ZoneName "sccmlab.net"

That’s it for configuring DNS – now let’s look at the DHCP Server Feature

To do this, you have to set a static IP address on your server. This we covered in Part 1, but if you totally forgot, don’t worry. Set a static IP address like this:

New-NetIPAddress -InterfaceIndex 2 -IPAddress 10.0.1.2 -PrefixLength 24 -DefaultGateway 10.0.1.3

Next, install the DHCP Server Feature.

Install-WindowsFeature DHCP -IncludeManagementTools

After this, a security group is created using the netsh command. The service is then restarted. When the following command is run, the DHCP Administrators and DHCP Users security groups are created in Local Users and Groups on the DHCP server.

netsh dhcp add securitygroups
restart-service dhcpserver

Now that the DHCP role and security groups are installed, we need to configure the subnets, scope and exclusions. Configure the DHCP scope for the domain. This will be the addresses that are handed out the to network by DHCP.

AddDhcpServerV4Scope -name "Lab Servers Scope" -StartRange 10.0.1.10 -EndRange 10.0.1.30 -subnetmask 255.255.255.0 -State Active
Next, authorize the DHCP server to operate in the domain:
Set-DHCPServerv4OptionValue -ScopeID 10.0.1.0 -DnsDomain sccmlab.net -DnsServer 10.0.1.2 -Router 10.0.1.3

Finally, the DHCP Server is added to the DC:

Add-DhcpServerInDC -DnsName sccm-ad1.sccmlab.net -IpAddress 10.0.1.2

We can verify the DHCP Scope setting using this command:

Get-DhcpServerv4Scope

We can verify the existence of this DHCP server in this DC with the following command:

Get-DhcpServerInDC

Restart the DHCP service:

Restart-service dhcpserver

 

SCCM Lab: Part 1 – AD Controller

frank August 30, 2019

I am currently setting up a new SCCM testenvironment in my home-lab – this will be one of (possibly) many quick-n-dirty how-to’s for setting up a functioning SCCM lab.

First things first – the lab wil consist of Server 2019 and Windows 10 servers and clients.
The SCCM version used is SCCM current-branch 1902.

All servers will be headless.

I have already installed a box-fresh Windows 2019 Standard server, without GUI. Continuing on from that, we will do the following:

  • Configure network settings
  • Configure Local date/time
  • Configure the firewall to allow pingreplies

Using sconfig – name your server something. In this case, I am calling it sccm-ad1.
Next up, edit your network card settings – configure your adapter with a static IP address, and set DNS server to 127.0.0.1.

Return to the main menu, and configure your local Date and Time settings to your correct timezone.

Restart your server – and jump in to a powershell session.

I like my labcomputers replying to pingrequests, so to allow this – type in the following command (applies to IPV4):

New-NetFirewallRule -Displayname "Allow inbound ICMPv4" -direction Inbound -Protocol ICMPv4 -IcmpType 8 -remoteaddress <your subnet> -action allow

Restart your server.

Next up, we will install the AD Controller role.
Jump in to a Powershell session, and enter the following:

Get-WindowsFeature AD-Domain-Services | Install-WindowsFeature

let the installation finish, then enter the following:

Import-Module ADDSDeployment

Then, to install the new AD controller in our new forest, enter the following:

Install-ADDSForest

Continue by entering your domainname of choice, and a SafeMode password. After installation is finished, the server will restart and finish configuration.

Next I’ll create a new AD user in this domain, for administrating the environment. Do this by entering a Powershell session, and enter:

New-ADUser -name "Awesome" -Givenname "Awesome" -Surname "Sauce" -SamAccountName "Awesome" -UserPrincipalName "awesome@your.domain"

Test that you have successfully created the user by entering:

Get-AdUser Awesome

You will find the user is not active yet. Before enabling the user, set the password for that user.

Command to set password:

Set-ADAccountPassword 'CN=Awesome,CN=users,DC=sccmlab,DC=net' -Reset -NewPassword (ConvertTo-SecureString -AsPlainText “YourPassword” -Force)

Add the user to Domain Admins group

Add-AdGroupMember ‘Domain Admins’ Awesome

And there you have it – your very own Headless Windows Server 2019 AD Controller.

-F

Windows: Server stuck in shutdown after installing patches

frank March 31, 2016 No Comments

One of my servers in my labenvironment refused to gently reboot after installing a ton of patches that I.. uhm.. forgot to install.
The “restart-computer -computername DC1” cmdlet wouldn’t do anything, as it returns with : Restart-Computer : Failed to restart the computer dc1 with the following message: A system shutdown is in progress.

Figures, the server is physical, and about an hour drive away.

The (somewhat crude) solution:
Use PSkill.exe to kill the TRUSTEDINSTALLER process. (Note: this is not recommended, but what the hell, this is a testenvironment).

1. Download the utility here
2. Extract it somewhere, open a elevated CMDlet window, and CD yourself into the exctracted folder.
3. Use this command to kill the respective hangig process: pskill.exe \your-server your-process (In my case: pskill.exe DC1 TRUSTEDINSTALLER).

The server then booted after about a minute, and about 15 minutes later it was available through RDP.

-F

Windows: Modify Automatic (Delayed start) windows service thresholds

frank February 24, 2016 No Comments

I wanted to modify the delayed start time threshold for one of my services.
If you want to tweak your delaytime, do the following in regedit:

1. Open Regedit.
2. Navigate to your service, in my case it was HKLMSYSTEMCurrentControlSetservicesPlexService
You should see that the “DelayedAutostart is set to 1.
3. To increase the default delay of 120 seconds, right click the registry key and add new key AutoStartDelay (DWORD (32-bit), like mine: HKLMSYSTEMCurrentControlSetservicesPlexServiceAutoStartDelay
4. Set the decimal to your default value. Like mine: 300
5. Reboot, and see if the service autostarts after x seconds.

– F

Windows: Autologon for Domain User

frank February 24, 2016 No Comments

I have some machines in my lab at home that, due to heavy testing and other stuff, reboots often.
Some of my applications are dependent on the user beeing logged on to function properly – so instead of manually logging on each time my server boots, I fiddled around in registry to make the domain user log on automatically.

This, of course, is not recomended in any production environment, but for lab purposes, I find this trick very useful.

1. First, open regedit on the machine you want to fiddle with.
2. Navigate to HKLMSoftwareMicrosoftWindows NTCurrentVersionwinlogon
3. Make a backup of winlogon.
4. Change the following values (you may need to add some of them if they’re not present).

AutoAdminLogon = 1 (String Value Key) (0 means off, 1 means automatic)
DefaultUserName = Username (String Value Key)
DefaultPassword = Password (String Value Key)
DefaultDomainName = yourdomain.com (String Value Key) (Only needed if this computer has joined a domain)

4. Reboot

The user should now log on automatically.
As you see, the password is displayed in clear text, so beware.

– F