Removing Cisco Umbrella from a server

[YeOldeStonecat]

I took over a client from a nearby competitor...and they have Cisco Umbrella installed on the server.
I do not have experience with it, so wanted to check before I blew up the server. I wish to uninstall it....but do it properly, completely, thoroughly, without unexpected surprises. So...if anyone is familiar with this product, there's a program installed (Cisco Umbrella), the servers TCP/IP v4 properties have itself as primary DNS (loopback), and OpenDNS's 208.67.222.222 as secondary DNS.

When I go to DNSMGMT.MSC, and go to forwarders, there are a couple of oddball EC2 amazon servers listed in there that I don't recognize.

So I'm assuming I can uninstall that Cisco Umbrella from Programs/Features, and then remove the secondary DNS in TCP/IP v2 props, and then do my normal 9.9.9.9 in DNSMGMT.MSC forwarders. Probably give the server a bounce afterwards after flushing DNS cache.

 

[Markverhyden]

I'd check all the other devices to make sure they aren't tied into that product.

 

[Sky-Knight]

The agent itself removes cleanly from add / remove programs, there are some drivers involved. I had to stop using OpenDNS due to it screwing up the DNS path entirely too much but removal has never given me a problem.

The configuration of the DC's DNS to forward to other DNS servers is quite normal, and yeah you'll want to probably change that but at the same time it doesn't really break anything... OTHER THAN, until the other provider removes them from their portal, the OpenDNS servers will be filtering in accordance with the other MSP's configured policies.

So yeah, your process is fine, and it works. And yes, as Mark indicated you'll want to get rid of the umbrella agent on everything else too. Until you do, you're more likely to have issues with desktops not being able to find their domain controller because with that agent installed the configured DNS on the NICs simply doesn't matter.

 

[YeOldeStonecat]

Nothing found on workstations relating to Umbrella. DHCP server set to just hand out servers IP for DNS, nothing else. I've already swept through those....holy crap what a butchered mess.
Prior IT has Ninja RMM on them, plus that horrible....webroot. I swear I should nuke 'n pave them....I've had horrible experiences with any computers that webroot even got within 50 miles of.

Somehow the prior RMM tools really mangled up Microsoft updates services. For a CPA firm, so many "old" win10 versions...1909 for most of 'em, some older. Doing a check for updates, they "hid" that with a registry key. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
SettingsPageVisibility hide:windowsupdate
Created a script and ran it in Syncro to delete that key.

But something still deep in there. So then created a script to blow out all prior group policies held local on the rigs.

 

[YeOldeStonecat]

Pulled Umbrella client from server...
Local TCP/IP v4 primary DNS left to loopback, removed secondary DNS which was pointing to OpenDNS public server
DNSMGMT.MSC...removed those Amazon servers and just left it to the Quad9 server I usually use.

So yeah...was that simple and straightforward. Just wanted to be sure, hoping someone had experience with their product from the DC side of things.

 

[YeOldeStonecat]

And checking for updates, even manually running media creation tool to update, blows up
Found out C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS\setupconfig.ini exists in these computers, and no WSUS on any servers, probably a prior server. No GPO pushing that.
Whacking that file seems to allow updates to push through.

 

[Sky-Knight]

You might find it easier to push a GPO that has proper WinUpdate settings. Since removing GPOs and similar tools doesn't actually revert the changes, simply stops enforcing them.

And interesting, about setupconfig.ini because as far as I knew that required Enterprise versions of Win10.

 

[YeOldeStonecat]

You might find it easier to push a GPO that has proper WinUpdate settings. Since removing GPOs and similar tools doesn't actually revert the changes, simply stops enforcing them.

And interesting, about setupconfig.ini because as far as I knew that required Enterprise versions of Win10.

Workstations store policies in these two directories, so in a long unknown history of old active directory, where you may not have GPOs properly retired, you can just whack any remnants by doing this on workstations..(I pushed out this script to 'em all)

I also suspect many settings were butchered from scripts or home made pushed reg updates, or prior RMM agents.

RD /S /Q "%WinDir%\System32\GroupPolicy"
RD /S /Q "%WinDir%\System32\GroupPolicyUsers"