Configure CleanBrowsing DNS for Different Users on Windows

CleanBrowsing provides you a DNS-based content filtering service. The configuration, however, is often up to the user of the service. As much as we assume it’s easy, we also realize there are a lot of things we forget when ti comes to administration. Our enterprise customers have system administrators, but what about our small businesses and individuals?

This article is designed to help bridge that gap. It will show how to configure DNS according to a specific user. This will be done at the device level, but can also be replicated by network administrators using Active Directory and GPO.

For this example, we’ll use the following:

ParentThis will be the administrative user. This user has full administrative rights to the machine. You can’t limit an administrator user, that’s by design with Windows.
ChildThis will be the standard user. They can access the machine, but don’t have administrative rights. This means you can limit what the user can, and can not, do.

Disclaimer: This guide assumes some technical competence. Deploying these steps can cause harm to your machine. Deploy our recommendations cautiously, leveraging a test environment if possible. If you need consultation / technical services reach out to ColdPath; they offer services that can help deploy this on your machines and network.

Step 1: Create Environment Variables

Environmental variables are shortcuts that allow you to quickly navigate to specific locations on your machine. This is going to simply your life later when you’re creating the rules.

Env VariablePath

You will need to create the following directories: Repl\Imports\Scripts

We chose this location per Window’s recommendations on where system scripts should live. (ref:

To find the system variables do a search for environment variables, it will automatically pull up: Edit the system environment variables. Find a really good guide on how to create a new variable here:

Note: You do not have to create an environment variable, but it will make life easier later.

Step 2: Creating Window Scripts for each Profile / DNS

To make this work you will need to create two Windows BAT files. Each BAT file will contain specific instructions according to the profile you are using.

For this example, I will use the Free filters for each group (treating them as profiles on the paid accounts):

ProfileDNS ValuesBAT File Name

Each bat file should contain the following information respectively:

A. Parents Profile

@echo off

:: Set Adult profile network settings

netsh interface ipv4 set dns "Wi-Fi" static primary
netsh interface ipv4 add dns "Wi-Fi" index=2

A. Child Profile

@echo off

:: Set Child profile network settings

netsh interface ipv4 set dns "Wi-Fi" static primary
netsh interface ipv4 add dns "Wi-Fi" index=2

It’s important you separate the files accordingly and carefully annotate the DNS values in each file. Each script will be called individually.

It should look something like this when you are done:

Step 3: Create a Rules for each Profile

There are a couple of different ways you can try. The most common approach is call these scripts at “log on”. Unfortunately, there are some User Access Control (UAC) issues with Windows that we have found to make this unreliable on individual devices (not applicable for AD / GPO users).

For individuals, we recommend using the Task Scheduler feature. We have found this to be the most effective solution.

Open your task scheduler by searching for it in your windows bar.

When it opens, create a new task:

The create task option is going to open a new dialog.

1 – Give it a name, for this example we went with CB-Parent;

2 – Under Security Options, choose which user is going to run the script. Make sure this user is the administrator.

3 – Select the option that reads “Run with highest privileges” this is especially important when it runs on the standard user account.

Switch to the Triggers tab:

This panel helps tell the system “When” the task should occur.

Here you are going to create two unique triggers:

At log onRun when the user logs in.
On connection to user sessionRun when the session is initiated. This is especially important because if the user doesn’t log out (e.g., locks the account, or quickly switches to another account, the ‘at log on’ won’t work).

Here are some important options that must be selected, or set, in each trigger:

Specific UserThe specific user is important, it’s going to tell the task which user the rules should be applied to.
Connection from local computerYou want the local connections when you’re working locally on one machine
Repeat TaskRepeat 5 minutes, for a duration of indefinitely
EnabledMust be enabled

It will look something like the image below. You will create two separate triggers, each with the corresponding value. You have to create a trigger for the “log on” and “user session” separately.

The trigger should look something like this:

Tech Note: Don’t forget to create another trigger for Log On.

Switch to the Actions tab:

This panel will tell the system “what” to do.

Here you are going to create one action – Start a Program. This is also where you will appreciate the variable you created in Step 1.

The action should look something like this:

Tech Note: If you don’t have the environment path, paste the entire directory path in it’s place.

Step 4: Create the Task for the Child Profile

Once you have create the task for the Parent Profile, repeat the steps to create one for the Child.

The key things to remember with t he child is to:

A. use the correct bat file;

B. make sure you choose the correct user in the tigger;

C. make sure you choose the correct user in the settings to run the script;

There are two unique user options that have be selected, it’s easy to mix them up and doing so will make it not work.

Although it might feel complicated at first, it’s a straight forward process. After creating one task, the second, third, fourth will become that much easier.

If you’re a paid customer you can use the same steps above to apply different profiles to different users on the same Windows Machine.

The end result will be that the DNS will be set on the device according to the user that is logging in. It will take into consideration instances where a user doesn’t log out, but instead locks the screen, or switches users dynamically.

The same principle can be applied to devices on Active Directory (AD) or organizations using GPO to manage multiple devices.

Was this article helpful?

Related Articles