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

OpenHab Automation: Turn on and off lights based on sunset and sunrise

frank August 15, 2019

So, for quite some time now I have been wanting to automate the exterior lights of our house. OpenHAB2 (OH2) lets you do this quite smoothly by using the Astro binding.

Start off by fetching the Astro Binding via the OH2 controlpanel. Configuration > Bindings.
Click the Plus icon, and select Bindings in the top table – searching for Astro will reveal the binding you want (I am currently on binding-astro – 2.4.0). Select Install, and let it finish. We will now continue in the configurationfiles.

In your Openhab-Conf folder, under Things, create an empty file and call it astro.things.
In this file, at a bare minimum, you should put in this string:

astro:sun:home [ geolocation="10.12345678,5.12345678", interval=300]

The first three statements are calling the Astro function, the SUN object, for the HOME location. The two statements in the square brackets are geolocation and polling interval – here you need to find your longtitude and latitude from a map site (google maps is fine), and replace the digits in the example above.
A pollinginterval of 300 seconds is sufficient for my own environment, and I rarely need to know where the sun is for as often as every 5 minutes – but feel free to adjust this at your own need.

Save the file, and see that you dont receive any errors in your logs.

Next up, head on over to your items folder. Here we will add the sun-items based on the astro thing value you just created.

Create an empty file, call it astro.items. Here you will add three strings:

DateTime    Current_DateTime     "Today [%1$tA, %1$td.%1$tm.%1$tY]"                <clock>  (Astro) {channel="ntp:ntp:local:dateTime"}
DateTime    Sunset_Time          "Sunset [%1$tH:%1$tM]"                            <sun>    (Astro) {channel="astro:sun:home:set#start"}
DateTime    Sunrise_Time         "Sunrise [%1$tH:%1$tM]"                           <sun>    (Astro) {channel="astro:sun:home:rise#start"}

The first item tells your environment based on your geolocation what time it is right now.
The second item tells you when the sun sets.
The third item tells you when the sun rises.

Based on the second and third item, we can create rules that, in this example, turns our porch- and streetlight on and off, based on the sunset and sunrise.

Head on over to your Rules folder, and create an empty file, calling it outside_lights.rules

The first rule will turn your lights on. It looks something like this:

rule "outside lights ON"

when
    Channel 'astro:sun:home:set#event' triggered START
then
    if (outside_lights.toggle.state == OFF)){
        logInfo("Outside_lights", "All lights are off, turning them on.")
        outside_lights.toggle.sendCommand(ON)
    }
    else {
        logInfo("Outside_lights", "All lights are on - doing nothing.")
    }
end

And for the rule that turns the lights off, we get something like this:

rule "outside lights OFF"

when
    Channel 'astro:sun:home:rise#event' triggered START
then
    if (outside_lights.toggle.state == ON)){
        logInfo("Outside_lights", "All lights are oN, turning them OFF.")
        outside_lights.toggle.sendCommand(OFF)
    }
    else {
        logInfo("Outside_lights", "All lights are off - doing nothing.")
    }
end

Save these in the same outside_lights.rules file, and save it. See that you don’t receive any errors in the log.

Remember to chagnge the rules to fit your light items – but this should be obvious 🙂

Now, if all is configured correctly, you will see that your lights will turn off and on, based on the sunrise and sunset in your area.

Happy automating!

-F