Why this has to be a ‘thing‘ in a business version of Windows I’m not really sure, but if you want to remove these adverts from the Windows Search function.
They are called ‘Search Highlights‘ or ‘Dynamic Search Box‘.
Solution: Remove Search Adverts
Option 1 Remove Search Adverts with Domain Group Policy
In a domain envronment we can simply crete a GPO and link it to the the computers you want to ‘remove’ this ‘feature’ from. On a domain controller > Administrative Tools > Group Policy Managment Console > Selct a policy that’s linked to the computers OU that the affected machines are in, or create a new policy and edit it.
Option 2 Remove Search Adverts with Local Group Policy
If your PC is in a workgroup or simply a stand alone PC you can acheive the same by using Local Policies. (Note: Not avalable with Home versions of Windows). In the start menu search for and execute gpmc.msc
Option 3 Remove Search Adverts with Local Settings
Another option, is to go to settings.
Privacy and Security > Search Permissions.
Scroll all the way to the bottom > More Settings > Show Search Highlights > Off > Then reboot the PC.
Option 4 Remove Search Adverts within The Registry
If you have a home edition of Windows then sometimes it’s easier to simply set this in the registry. Locate and execute regedit.
Navigate to.
[box]
Computer > HKEY_CURRENT_USER > Software > Microsoft > Windows > CurrentVersion > SearchSettings > IsDynamicSearchBoxEnabled
[/box]
Set to 0 (Zero) for Disabled.
Allow Search Highlights Option Missing From GPO
If you attempt to disable this but find the option missing like so.
You need to update your policy definitions for Windows 11 the updates are here and here. When you execute the updates, it will put the policy definisions in an odd place make sure you take a note of where the definisions are getting put.
Now you simply need to copy the ADMX and ADML files to the correct location on one of your domain contollers, to understand how to do that read the following article.
We have had ADMX files for group policies for ages now, they are the successor to the older ADM files. They only really trip you up if you have something unusual to do, (likeroll out LAPS, or Forefront, or Customising Office Deployments.)
In most cases you will want to have a central store in your Windows domain, so the clients can see the ADMX files, (and ultimately enforce the policies within them).
Solution: PolicyDefinitions
You probably already have ADMX files on your windows clients/servers, look in C:\Windows\PolicyDefinisions. So if you have installed any new ADMX files, they will get put in this folder on your local machine, (or domain controller).
Do you already have a central PolicyDefinitions store? It’s easy to find out, from any domain joined machine, run the following command;
If theres a PolicyDefinitions folder already there, half your work has been done for you!
Copying Files to the Central PolicyDefinitions Store
ADMX Files are usually accompanied by an ADML file, while the ADMX files live in the PolicyDefinitions folder, the ADML files are ‘location specific’, if you look in your PolicyDefinitions folder you will see another sub folder for your ‘locale’. Below you can see mine is en-US (English US) your ADML files will live in here.
IMPORTANT: As you can see, (below). I’ve navigated to the PolicyDefinitions folder ON A DOMAIN CONTROLLER, at the following path;
DON’T Try and copy the folder, (or ADMX and ADML) files to the network path of SYSVOL, or you ‘may’ get permission errors, (see error below).
You can simply copy the entire PolicyDefitions folder across if it does not already exist, or copy individual ADMX/ADML files (to the folder locations outlined above).
Now on your domain controller, Administrative tools > Group Policy Management console, create (or edit and existing policy). If you are setup correctly you should see this;
If something is wrong you will see this;
Copying PolicyDefinisions and ADMX/ADML Files: Access Denied
If this happens, you need to ensure you are NOT trying to copy folders or files to the network path of the SYSVOL folder, Open the LOCAL path to the SYSVOL folder directly on a domain controller.
Related Articles, References, Credits, or External Links
If you have arrived here, you have either noticed that the time is wrong on your server(s) or client PC(s), or you have looked in the event viewer and seen one of the following events being logged. Event ID’s 12, 22, 29, 36, 38, 47, and 50.
Event ID 12 (W32 Time Time Provider NtpClient: This machine is configured to use {text omitted}, but it is the PDC emulator…).
Event ID 29 (The time provider NtpClient is configured to acquire time from one or more time sources…).
Event ID 36 (The time service has not synchronized the system time for 86400 seconds…).
Event ID 38 (The time provider NtpClient cannot reach or is currently receiving invalid time data from…).
Event ID 47 (Time Provider NtpClient: No valid response has been received from manually configured peer…).
Domain Time Problem Events – On Domain Members
Event ID 50 (The time service detected a time difference of greater than 5000 milliseconds for 900 seconds…).
Event ID 22 (The time provider NtpServer encountered an error while digitally signing the NTP response for peer…).
Solution : Domain Time Problems
Setting domain time is a TWO-STEP process, set the time correctly on the PDC emulator, then let the clients take their time from the PDC emulator.
Locate the PDC Emulator
1. On a domain controller, Windows Key+R > netdom query fsmo {Enter}.
2. Take note of the PDC name and go to that server.
NTP Firewall config (Domain Time)
1. Ensure UDP Port 123 is open outbound from the PDC Emulator. How this is done will vary depending on your firewall vendor. If you have a Cisco ASA or a Cisco PIX see my article here.
To Test Use NTPTool
Below either the port is blocked (or the hostname/IP of the external NTP server is incorrect);
This is how it should look, every-time you press query you should get a response, now you know the correct port is open;
Configure the PDC Emulator to collect Reliable Domain Time
Of course our PDC Emulator is also a domain controller, so we need to link a GPO to the domain controllers OU. But we dont want all DC’s getting their time from an external source, so we will create a WMI filter to ensure the policy will only apply to the PDC emulator server.
Administrative tools > Group Policy Management > WMI Filter > New > PDC-Emulator-Only > Add > Select * from Win32_ComputerSystem where DomainRole = 5 > OK.
Don’t panic if you see this error > OK > Save.
Create a new GPO linked to the Domain Controllers OU.
Change the policy so it uses your WMI filter;
Edit The Policy, and navigate to;
[box]Computer Configuration > Policies > Administrative eTemplates > System > Windows Time Service > Time Providers[/box]
Configure Windows NTP Client
Enable the policy > set the NtpServer setting to server-name(comma)stratum-type(space). If you get this wrong you wont sync, and you will see this error.
Enable Windows NTP Client
Enable the Policy (The server still needs to get its time from the external source!)
Enable Windows NTP Server
Enable the policy (The server also needs to provide time to the domain clients).
Save and exit the policy editor, then on the PDC emulator force a policy update and resync the time. Finally run rsop to make sure the settings have applied.
Setting PDC Emulator Time From Command Line
1. On the PDC emulator Windows Key+R > cmd {Enter}.
2. At command line execute the following four commands;
[box]
w32tm /config /manualpeerlist:ntp2d.mcc.ac.uk /syncfromflags:manual /reliable:yes /update
net stop "windows time"
net start "windows time"
w32tm /resync
[/box]
Note: If you are NOT in the UK or simply want to use a different NTP time server go here for alternatives.
3. Look in the servers Event log > System Log for Event ID 37.
---------------------------------------------------------------
Event Type: Information
Event Source: W32Time
Event Category: None
Event ID: 37
Date: xx/xx/xxxx
Time: xx:xx:xx
User: N/A
Computer: {servername}
Description:
The time provider NtpClient is currently receiving valid time
data from ntp2d.mcc.ac.uk (ntp.m|0x0|10.0.0.1:123->130.88.203.64:123).
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. —————————————————————
4. You will also see Event ID 35.
---------------------------------------------------------------
Event Type: Information
Event Source: W32Time
Event Category: None
Event ID: 35
Date: xx/xx/xxxx
Time: xx:xx:xx
User: N/A
Computer: {servername}
Description:
The time service is now synchronizing the system time with the time source
ntp2d.mcc.ac.uk (ntp.m|0x0|10.0.0.1:123->130.88.203.64:123).
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. —————————————————————
Step 2 Check the domain clients
This is all you should need to do, because, (by default) all Domain clients get their time from the PDC when they log on, but to check;
1. Windows Key+R > cmd {enter}.
2. Execute the following command;
[box] w32tm /monitor [/box]
3. You will see the time this client can see, on all the domain controllers.
(In the case above the time on server-dc is way out, address that first – (it was an old Windows 2000 server and running “net time server-pdc” {enter} fixed it).
4. Once all the domain controllers have a time that’s accurate (like the last three in the example above), then proceed.
5. Execute the following commands on a client machine;
[box]
net stop "windows time"
net start "windows time"
w32tm /resync
[/box]
6. The machines event log should show the following successful events;
Event ID 37 (The time provider NtpClient is currently receiving valid time data from..).
Event ID 35 (The time provider NtpClient is currently receiving valid time data from..).
Setting Domain Clients Time via GPO
As already outlined you should not need to do this, (as it’s the default setting,) but if there’s a problem you can force domain clients to look at your PDC emulator for reliable time.
Create a GPO, and link it to the OU containing the computers you want to sync’
Edit the policy and navigate to;
[box]Computer Configuration > Policies > Administrative eTemplates > System > Windows Time Service > Time Providers[/box]
Configure Windows NTP Client
Enable the policy > Set the NtpServer to {Your-PDC-Name},0x9 > Set the Type to NT5DS.
Enable Windows NTP Client
Enable this policy.
Testing Client NTP Settings
Either run;
[box]w32tm /query /status[/box]
Or run RSOP.
Related Articles, References, Credits, or External Links
We used to have Microsoft LAPS, now we have Windows LAPS!LAPS is a solution that lets’ you store admin passwords ‘elsewhere‘ be that in your local Active Directory or Azure Active Directory*. Unlike previously, where you had to deploy/install client software, it’s now built into Windows from the following versions.
Windows 11 22H2 – April 11 2023 Update
Windows 11 21H2 – April 11 2023 Update
Windows 10 – April 11 2023 Update
Windows Server 2022 – April 11 2023 Update
Windows Server 2019 – April 11 2023 Update
*Note: Is in the pipeline at time of writing traditional (on-premises) AD only is supported.
The premise is that instead of having a single (easily compromised) local admin password (or DSRM password on a DC) for your assets you can have a different password (that can be controlled with a complexity policy) for each client/server and that password is stored securely in Active Directory, (as an attribute of the computer object).
Backup to Azure AD
Backup to Local (On-Premises) AD
Azure AD Joined
Yes
No
Local (On-Premises) Joined
No
Yes
Hybrid Joined
Yes (if not backed up to on-premises AD)
Yes (if not backed up to Azure AD)
Workplace Joined
No
No
Solution: Windows LAPS
Firstly, FULLY update all the domain controllers in the domain.
On a DC you can load the LAPS module and look at the commandlets.
[box]
ipmo LAPS
gcm -Module
[/box]
From these commandlets the first one we need to use is Update-LapsAdSchema, this will extend the active directory schema and add the LAPS attributes to the computer objects.
[box]
Update-LapsAdSchema
[/box]
It will ask you con conform you can watch each step by pressing Y – or if you’re lazy (like me) simply press A {Enter}.
You can’t really see what it is doing, but if you’re interested, you can run the same command again with a -verbose switch on it to see exactly what going on.
OK, but what has that done? Well as I said above, the computer objects have been extended and they now have ALL have the following attributes.
Note: Yes, there’s now a LAPS tab also, but there won’t be anything in there yet.
The next commandlet we need, Set-LapsADComputerSelfPermission, will grant the computer object the rights to manage its own LAPS password, You can set this on the root of the domain if you wish. Here I have all my computer objects in an OU called PNL so I’m applying that right at the TOP LEVEL OU, and it will apply to all children OUs.
Create a new GPO (or edit an existing one) that links to the OU where your COMPUTER objects live. (remember if managing DSRM passwords you will also need to link the policy to the Domain Controllers OU also).
Edit the Policy and navigate to;
[box]
Computer configuration > Policies > Administrative Templates > System > LAPS
[/box]
Note: If you have a LAPS folder directly under Administrative Templates, that’s for the older Microsoft LAPS settings!
Policies to edit;
Enable Password Backup for DSRM accounts : Enable
Name of administrator account to manage : Enable >laps.admin
Note: If you already have a local admin account, built into you master computer image for example, you can use that account instead.
Further policy to edit;
Password settings : Enable > (I accept the defaults)
The screen shot below shows how the policy should look before you exit the group policy editor.
Windows LAPS Local Admin
Here I’ve manually created the local user, you can either roll this out by script, GPO, or building the account into the your default image for OS deployment.
Retrieving Windows LAPS Passwords
Below you can see we can retrieve both a local Windows LAPS password for a client, or a DSRM password for a domain controller.
Simply click Show password and Copy password, and the password will be on the clipboard (as shown).
To get the password via PowerShell use the Get-LapsADPassword commandlet.
[box]
Get-LapsADPassword "PNL-Win11" -AsPlainText
[/box]
Troubleshooting Windows LAPS
The update also allows you to view LAPS event logs in the Event Viewer, like so.
Interoperability Microsoft LAPS and Window LAPS
If you have the older Microsoft LAPS running (i.e. Your end clients have the LAPS client software being deployed to them, then when the Apr 23 LAPS update is deployed to them and used, BOTH Systems may stop working. To fix this you need to disable Legacy LAPS by setting the following registry key on your clients.
[box]
HKLM > Software > Microsoft > Windows > CurrentVersion > LAPS > Config
[/box]
Create a new 32 bit DWORD value called BackupDirectory and set its value to 0 (zero).
Once the Azure AD element is fully released and supported, I’ll loop back and include that also.
Related Articles, References, Credits, or External Links
Controlling Microsoft Edge with Group Policy is pretty straight forward, you just need to ensure the msedge.admx and msedgeupdates.admx files have been added to your policy definitions store in the right folders. If you have no idea what I’m talking about, see the following article.
I have no problem with Windows 11, In fact I prefer its UI. But if experience has taught me anything, it’s that businesses will not be as quick to adapt Windows 11 as the general public. Some private companies spend ‘ages‘ testing production OS’s with various applications, and getting a change to that config can be a ‘challenge‘. So there are valid reasons for wanting to stop a Windows 11 upgrade.
Stop Windows 11 Upgrade (Single PC)
To do this you are essentially just creating a couple of registry keys, but as most people don’t like poking around in the registry, here’s how to do the same via PowerShell. Make sure you open an administrative PowerShell window (or you will get a permission error!)
Note: At time of writing, 21H2 id the newest release, if there’s a newer Windows 10 version, update your command accordingly.
Stop Windows 11 Upgrade (In a Domain)
In a corporate environment, you can set this via Group Policy, Create a new (or edit and existing) policy object thats links to Computers (not Users!)
Navigate to;
[box]
Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business
[/box]
I can’t see Windows Update for Business?If that folder is missing then you need to update your central policy store with the policy definitions for the latest version of Windows 10 (Search for ‘Administrative Templates (.admx) for Windows 10‘) to get the latest, then read the article above to see where to put them.
Enable the policy and then set it to the newest version of Windows 10 (at time of writing thats 21H2) > Apply > OK.
I was assisting a colleague to setup some AnyConnect for a client this afternoon, when all of a sudden I was met with this;
VPN
Logon denied, unauthorised connection mechanism, contact your administrator
Solution
This was a confusing one, I replicated the problem on my own test firewall. All I had done was change the AAA method from LOCAL to LDAP? It took me a while to figure out what was going on?
The reason why this is happening is because the GROUP POLICY your AnyConnect PROFILE is using does not have SSL enabled. (This makes no sense as it was working with LOCAL authentication, but this is how I fixed it).
You will be either using a specific group policy or the DfltGrpPolicy
[box]
IF USING THE DEFAULT GROUP POLICY
Petes-ASA(config)# group-policy DfltGrpPolicy attributes
Petes-ASA(config-group-policy)# vpn-tunnel-protocol ssl-client ssl-clientless
IF USING A SPECIFIC GROUP POLICY (Remember to include any, that already exist! e.g. l2tp-ipsec)
Petes-ASA(config)# group-policy PNL-GP-ANYCONNECT-ACCESS attributes
Petes-ASA(config-group-policy)# vpn-tunnel-protocol ssl-client ssl-clientless l2tp-ipsec
Note: This WONTWORK if you ‘force-tunnel’ or ‘tunnel-all’ remote VPN traffic, (if you are unsure Google ‘what’s my ip’ > Take note of it > Connect to AnyConnect and repeat the procedure, if your public IP address has changed to the IP address of the ASA then you force-tunnel/tunnel-all traffic).
With more people remote working now, I’m getting a lot more questions about RA-VPN and particularly AnyConnect. By default when connecting to any Cisco remote access VPN, it pretty much stops you connecting to anything outside the VPN tunnel, (unless you enable Split Tunnelling). This includes stopping you talking to assets on your remote network also.
This is basically ‘Good practice’, as a corporate entity you have authenticated a remote machine NOT the entire network it is on! But what happens when your MD want to print a work document on his/her home printer? Or you have a NAS drive at home with documents on it you can access while connected to the VPN?
Well, then you can ‘make a judgement call’ to whether or not you want to enable ‘Local LAN Access’ for your remote clients.
Full Disclosure: While this does not let everything on the remote clients LAN connect to the corporate network. If another client on a remote network was infected and compromised, and it proliferated its infection via the LAN, (to your authenticated remote client), then that client could infect the corporate network. This is what’s known as a ‘pivot attack’.
Solution
Assuming you are happy to enable local LAN access its a TWO STEP procedure. Firstly you enable Local LAN Access on the AnyConnect Client Profile, then you enable split tunnelling and allow all networks, (because you don’t know what all the remote network addresses may be).
Step 1: Add Local LAN Access to the AnyConnect Client Profile
If you are unfamiliar with ‘AnyConnect Client profiles’, they are simply XML files that are applied to to an AnyConnect Connection Profile, I already have one so I just need to edit it, And tick ‘Local LAN Access’.
What If you Don’t Already Have One? Not a problem. In the ASDM > Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Client Profile > Add > Give it a name > Set the Group Policy to your AnyConnect Group Policy > OK > Apply > Edit.
What Does User Controllable Mean? It means your users can enable or disable it, (see below.) If you untick this then they wont have that option.
Step 2: Add 0.0.0.0/32 to Split Tunnelling
You configure split tunnelling in your AnyConnect Group-Policy (ASDM > Configuration > Remote Access VPN > Network (Client) Access > Group Policies) Locate yours and edit it, navigate to Advanced > Split Tunnelling > Policy: Untick inherit, and set to Exclude Network List Below > Network List: Untick Inherit and click Manage.
Firstly: Create an ACL and call it “ACL-Local-LAN-Access’ > OK
Secondly: Select the ACL you just created and add an ACE to it > permit 0.0.0.0/32 > OK > OK > OK > Apply > File > Save Running Configuration to Flash.
Your remote workers will need to disconnect and reconnect before it will take effect. In some cases with older clients they need to reboot, (or have the AnyConnect service stopped and restarted.) If you experience problems make sure your clients have got the new XML file with;
If you connect to to a client via RDP then try and run the AnyConnect client, you will see one of these errors;
VPN establishment capability for a remote user is disabled. A VPN connection will not be established
VPN establishment capability from a Remote Desktop is disabled. A VPN connection will not be established
This, behaviour is default, and despite me trawling the internet to find a solution (most posts quote changing the local AnyConnectProfile.tmpl file, this file does not exist using Version 3 (I was using v 3.0.4235).
Update: With Early versions of AnyConnect version 4 it does not tell you what’s wrong, the VPN appears to connect and then disconnect quickly. If you have debugging on the firewall you will see the following;
Profile settings do not allow VPN initiation from a remote desktop.
Note: This is fixed in version 4.8 and you will se the error at the top of the page.
Solution
To solve this problem we need to create an AnyConnect profile, load the profile into the firewall, then associate that profile with your AnyConnect group policy. With modern versions of AnyConnect you can do that in the ASDM. With older versions you need to use the stand alone profile editor (see below)
Edit AnyConnect Profile With ASDM
Connect to the ADSM > Configuration > Remote Access VPN > Network Client remote Access > AnyConnect Client Profile.
Give the profile a name > Select a group policy to apply it to > OK.
AllowRemoteUsers: Lets remote users bring up the VPN, if this forces routing to disconnect you, it will auto terminate the VPN.
SingleLocalLogon: Allows multiple remote logons but only one local logon.
OR (older versions)
Apply the changes, and then save to the running configuration.
Edit AnyConnect Profile With Stand-Alone Profile Editor
1. First download the AnyConnect Profile Editor from Cisco. (Note: You will need a valid CCO account and a registered support agreement/SmartNet).
Update: The AnyConnect Profile Editor is now built into the ADSM, it becomes available once you have enabled any AnyConnect image. Once you have a profile created you can skip straight to step 3, and skip all the other steps.
If you cannot download the software here’s a profile (I’ve already created) you can use. If you are going to use this, jump to step 5.
2. Once you have installed the profile editor, launch the “VPN Profile Editor”.
3. The setting we want is listed under Windows VPN Establishment, and needs setting to “AllowRemoteUsers”, In addition I’m going to set Windows Logon Enforcement to “SingleLocalLogon”.
AllowRemoteUsers: Lets remote users bring up the VPN, if this forces routing to disconnect you, it will auto terminate the VPN.
SingleLocalLogon: Allows multiple remote logons but only one local logon.
4. Save the profile somewhere you can locate it quickly.
6. Browse your local PC for the profile you created earlier > Hit the “Right Arrow” to upload it > This can take a few minutes, depending on your proximity to the firewall.
7. Make sure the file uploads correctly > Close.
8. To associate this profile with your AnyConnect//SSL Group Policy, click Configuration > Remote Access VPN > Network (Client) Access > Group Policies > Locate the policy in use for your AnyConnect clients > Edit > Advanced > SSL VPN Client > Locate the “Client Profile to Download” section and uncheck the inherit button.
9. Click New > Browse Flash > Locate the profile you uploaded earlier.
10. OK > OK > Apply > Save the changes by clicking File > Save running configuration to flash.
11. Then reconnect with your AnyConnect Mobility Client software.
Related Articles, References, Credits, or External Links
