Fix: Uninstall Stubborn Non-UAC-Compliant Applications

If you’re in a situation where you’re trying to remove an application and you get a dialog box saying “Your System Administrator has set policies that prevent this installation,” even though you’re logged in as a Local Administrator, you have two choices:

1) Turn off User Account Control (UAC) for the computer

-or-

2) Use the workaround below to uninstall the program from an Administrator command prompt, thus saving you from having to disable the UAC security feature

(I hope you’ll agree that using the workaround makes far more sense than disabling UAC system-wide and having to reboot the machine!)

Here’s what you need to do:

1) Hop on the machine as a Local Administrator

2) Go to Start, and in the “Search programs and files” box, type in “cmd” (without quotes)

3) When “cmd” pops up, right-click on it and choose “Run as Administrator,” and click Yes on the UAC warning:

   

4)  At the command prompt, type wmic and hit Enter

5) Type in the following line, substituting ComputerName for the computer’s actual name:

   

    /node:ComputerName product get name,version,vendor

6) In the list of programs, you need to make a note of the exact program name… you’ll need this in the next step

7) Type in the following line, again with the ComputerName substitution, and also substituting ProgramName for the full name of the program as output from the last command:

    /node:ComputerName product where name=”ProgramName” call uninstall

8) You will have to type “y” (without quotes) and hit Enter in order for the uninstall to proceed.. at which point, you’re done!  The program should no longer be in your “Programs and Features” list!

Screenshot of process:

A return value of 0 indicates a successful uninstall.

How To: Deploy a Set of Power Settings to ALL Workstations

After having struggled with this for a mind-bendingly long time, I’ve finally found a solution that allows you, the Administrator, to deploy a Group Policy from a 2008+ server that allows you to manage Power Settings on XP and Vista/7 workstations.

Previously, as anyone who has lived this dream can attest, it was damn near impossible to do this from a 2003-based server, as the Group Policy settings didn’t propagate to Vista/7 workstations.  The best you could do was to select “High Performance” as your power scheme…

and hope against hope that none of the workstation manufacturers decided that “High Performance” was as follows:

Figure 1: Bite me, Dell

Even if you thought you’d be clever and create your own “Always On” power scheme on the server and then select that as your “Active Power Plan” in Group Policy, you’d quickly find out that the only power-related setting you could change was the display timeout.  Useless.

For Server 2008, the game has changed!  Took long enough, no? :-)

So, on your server, go to Start > Administrative Tools > Group Policy Management and drill down through your domain until you find the “Default Domain Policy” item in your “Group Policy Objects” container.  Right-click on it and choose Edit:

Really?  Default Domain Policy? If you already have special Group Policies or are more well-versed in the granular application of Group Policies to your organization’s computers (this is a Computer and a User-based setting), feel free to use whichever Group Policy you deem worthy.  This is just the quickest way to apply these settings across the entire domain.

You SHOULD run a GPResult to verify that the settings applied here aren’t overridden by other default policies—particularly if you’re running Small Business Server 2008.

You should NOT apply power settings to the Default Domain Policy if you are intending to implement a power scheme that is not of the “Always On” variety.

Remember that the Default Domain Policy applies to everything in the domain—including servers.  Will a server go into sleep mode if you set the Default Domain Policy to do so after 20 minutes?  I don’t actually know, but I don’t plan on finding out.

So, once you’re editing the policy (right-click, Edit), drill down through Computer Configuration > Preferences > Control Panel Settings > Power Options…

You are going to want to create new Power Options and Power Schemes for each OS type that you have in the organization.

For more details on this process, I’d recommend reading Alan Burchill’s post here:  http://blogs.technet.com/b/grouppolicy/archive/2009/09/30/configuring-a-power-plan-with-group-policy-preferences-by-alan-burchill.aspx

Ultimately though, this is what you’ll see on a SBS 2008 (non-R2) server:

You can see that I’ve created a Power Options set and a Power Scheme set for Windows XP.

I then did the same thing under User Configuration > Preferences > Control Panel Settings > Power Options (you know, just to be safe):

I also made sure to set the old “Administrative Templates”-based settings back to “Not Configured” so as not to override these new settings.

Unfortunately, as we see in the screenshots, when you’re configuring these settings on a SBS 2008 (non-R2) server, or any other 2008 non-R2 server, you cannot add power schemes for any OS other than Windows XP:

I also didn’t have any Server 2008 R2 Domain Controllers or Member Servers that I could adjust this Default Domain Policy on.

If I did, I could have simply added the Group Policy Management Console and gotten to editing the GPO, per the video below:

Thanks to Jeremy Moskowitz, by the way!

But again, I don’t have any R2-based servers on the network, so I can’t add a Vista+ Power Plan to the policy.

LAME!

***BREAK POINT***

If you do have a Server 2008 DC or Member Server, please skip this next section and go right to Adding a Power Plan for Vista+

So, to add this new policy, I had to find at least a Windows 7 Domain Member machine that I could install the Group Policy Management Console on.  I located one, and logged on as a Domain Administrator.

Here’s what’s next:

First, you need to download the Remote Server Administration Tools (RSAT) for Windows 7 (select Win32 or x64 depending on your current Windows 7 OS type as found by checking the Properties of My Computer):

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d

Next, go ahead and install the RSAT package you just downloaded.  You can skip the reboot for now.

Finally, you need to go to Control Panel > Programs and Features and click on the “Turn Windows features on or off” link.  Drill down through the feature list as shown until you can check the box next to “Group Policy Management Tools” and click OK:

Thanks to Jeremy Moskowitz’s video below:

You will indeed now have to reboot after installing this feature.

And hey… once you restart, log back in as a Domain Administrator, find the Group Policy Management console:

…and find your way back into editing the Default Domain Policy, you will find that which you seek:

Adding a Power Plan for Vista+

aka. Another Wonderful “Gotcha!”

After trying to add the Power Plan like the above screenshot, I discovered that you couldn’t set the timeouts to “Never,” you could only select a number of minutes.  Double lame!  Not wanting to set the number of minutes to “0” and having to cross my fingers in the hopes that the client machines didn’t take it literally and all go to sleep at the same time, I wanted to find out whether or not a “0” would equate to “Never” in the normal Power Plan settings:

On the 7 machine that I installed the GPMC on, I added a new power plan from the Control Panel > Power Options:

I named it [CLIENT]-AlwaysOn… and proceeded to edit it to as many of the “Keep this computer running all the time” settings as I could find:

I then checked the properties of the Power Plan in the Default Domain Policy… and yes, a “0” is equivalent to “Never.”

Phew!

(Having to always create the Power Plan on a 7 machine would have sucked!)

So, back to the policy creation… I created the Vista+ policy in both User Configuration and Computer Configuration… and just a tip to save you some time—you can copy-paste :-)

I then ran a GPUpdate /force on my test workstation… aaaand…

Windows XP: Great Success!

Windows Vista & 7: FAIL.

I could see that the new power policies (both the “CC” and “UC” ones I’d created earlier) showed up in the end users’ Control Panel > Power Options, but had no idea why the Vista/7 “Power Plan(s)” weren’t actually being set as active… I confirmed that I’d checked the box for “Set as the active power plan”… after Googling, I found this:

So… change both your “User Configuration” and “Computer Configuration” power plans to “Update” while making sure the “Set as active power plan” checkbox remains checked:

Run another GPUpdate /force and you should be in business:

There, I just saved you 8 hours of your life.  You can thank me later :-)

Tip: Comcast-Leased Modems: Verify DOCSIS Compatibility & EOL Status

I just had an interesting run-in with Comcast in lining up an appointment to fix my horribly intermittent Internet service.

I’d been paying $5/month to lease a modem for the few years or so—and it turns out that the modem they’d been leasing me (a Terayon TJ715x http://mydeviceinfo.comcast.net/DisplayCMDevice.php?device=109) was only DOCSIS 2.0 compatible… which, in turn, means that the 16 Mbps service I was paying for was effectively limited by the modem to 12 Mbps.

I negotiated a credit for the modem rental fees and got the next 6 months for $29/month… but…

If you have Comcast and have anything over the 12 Mbps service level, you should probably check to see if your modem is DOCSIS 3.0 compatible… and if not, demand a credit and threaten to jump to Clear.  They’ll hook you up :-)

While you’re checking, you should also see if your leased modem has been end-of-lifed.  My Terayon was EOLed back in 2009 (!), which may be part of the issue.

http://mydeviceinfo.comcast.net/

Also, as a side note… if you schedule an appointment and receive a robocall an hour later stating, “Comcast has just fixed a service issue in your area, and it’s likely that this may have fixed the problems you were experiencing.  If you are no longer experiencing issues and would like to cancel your appointment, press 1,” do not cancel the appointment, even if things appear to be working.  I got burned on this on Sunday and a co-worker mentioned a similar experience.

Fix: Best Practices for Cleaning Up Superfluous Firewall Rules & NAT Policies on a SonicWALL NSA

I must first profess that I

 SonicWALL

I’m also a huge fan of the Public Server Wizard:

That being said, I will admit that when you use the Public Server Wizard to set up access to an externally-accessible resource, you can, over time, end up with a confusing litany of NAT Policies, Access Rules, Service Groups and Address Objects.  In some cases, I’ve seen instances where the previous Administrator has run the Public Server Wizard for each port that needed opened to the same internal resource.

Trust me, this will make your head hurt when you’re trying to parse “which policy/rule does what?”

You’ll end up looking at something like this, using the example of an Administrator that ran the Public Server Wizard to open ports 80, 443 and 25 to a SonicWALL E-Mail Security appliance:

6 Address Objects: E-Mail Security Public, Email Security Public, ES300 Public, E-Mail Security Private, Email Security Private, ES300 Private

3 Service Groups: E-Mail Security Services (contains HTTP(80) service), Email Security Services (contains HTTPS(443) service), ES300 Services (contains SMTP(25) service)

9 NAT Policies: Inbound, Outbound and Loopback policies for all Service Groups correlated to all Private & Public Address Objects

15 (potentially) Firewall Rules: WAN > LAN, LAN > WAN, LAN > LAN, VPN > LAN and LAN > VPN rules that correspond to the NAT policies

This is my usual reaction to seeing a configuration like the one above:

So, when I’m charged with cleaning this up, I generally do three things:

1) Swear profusely

2) Get caffeine

3) Back up the current configuration

4) Follow my time-tested best practices listed below

Here’s what I’ve found to be the fastest, most efficient way to clean up a mess like this:

1) In case you hadn’t already done so, back up the current settings:

    A) System > Settings > Export Settings

    B) Save the .exp file

    I also like to save the Tech Support Report:

    A) System > Diagnostics

    B) Check all boxes shown and hit Download Report:

        

    C) Save the report to a secure location (it contains unencrypted information)

2) Identify your duplicative or in-need-of-consolidation rules/policies/objects/groups (best done by perusing NAT Policies under Network > NAT Policies and selecting Custom Policies until you have a clearer understanding of what goes where and which rules/policies/objects/groups are redundant):

   

    Tip: Look for items with similar names/devices… like “E-Mail Security,” “Email Security” and “ES300”

3) Pick one good set of rules/policies/objects/groups and remember the prefix… per the earlier example, I’ve decided to keep the rules/policies/objects/groups with the “E-Mail Security” prefix, and I will eventually consolidate and ditch the “Email Security” and “ES300” prefixed rules/policies/objects/groups

4) Go to Network > Address Objects and make sure to select “Custom Address Objects”:

   

5) Locate and edit each of the Address Objects that have the prefixes that you are trying to eliminate (again, in this case, “Email Security” and “ES300”)… edit each Address Object where you see these prefixes… and add your own prefix called “FIX:”—this will help you easily identify which rules/policies/objects and groups will eventually be consolidated & removed:

   

    Now that all of the superfluous Address Objects have been marked, we’ll work on Services.

6) Go to Network > Services, and choose Custom Services:

   

    

7) Again, in this scenario, there are multiple Service Groups that were added by the Public Server Wizard that need to be consolidated… here’s the list: E-Mail Security Services (contains HTTP(80) service), Email Security Services (contains HTTPS(443) service), ES300 Services (contains SMTP(25) service)

    Since I’ve decided to keep items with the “E-Mail Security” prefix, I will:

    A) Re-name “Email Security Services” and “ES300 Services” to add the “FIX:” prefix

    B) Add the Services listed in the “FIX:” prefixed groups to the “E-Mail Security Services” group:

       

        Don’t forget this step!  If you fail to add all services to the “keeper” Service Group, things will break!

8) Go to Firewall > Access Rules and choose All Rules:

   

9) Go through all of the Firewall Rules and un-check any rules that have the “FIX:” prefix, making sure that anything with a name other than “Any” is prepended by “FIX:”—if you see a rule that does not have a Source, Destination or Service (other than “Any”) that is not prefixed by “FIX:”, then STOP and re-check your work... you must’ve missed renaming a Service Group or Address Object:

   

10) Test external connectivity to the key services/servers in question and verify that everything still works as needed:

   

11) If everything is still good, go ahead and delete the aforementioned Firewall Rules you just disabled:

   

12) Go back into Network > NAT Policies and select Custom Policies:

   

13) Do the same thing we did for the Firewall Rules… Go through all of the NAT Policies and un-check any policies that have the “FIX:” prefix, making sure that anything with a name other than “Any” is prepended by “FIX:”—if you see a policy that does not have an Original or Translated name (other than “Any”) that is not prefixed by “FIX:”, then STOP and re-check your work... you must’ve missed renaming a Service Group or Address Object:

   

14) Once again test external connectivity to the key services/servers in question and verify that everything still works as needed:

   

15) If everything is still good, go ahead and delete the aforementioned NAT Policies you just disabled:

   

16) Go back to Go to Network > Address Objects and make sure to select “Custom Address Objects”:

   

    

    …and then delete any Address Objects with the “FIX:” prefix:

   

17) Go back to Network > Services, and choose Custom Services:

   

    …and then delete any Service Groups with the “FIX:” prefix:

   

18) It’s time to back up the modified settings one last time:

    A) System > Settings > Export Settings

    B) Save the .exp file

    I also like to save the Tech Support Report:

    A) System > Diagnostics

    B) Check all boxes shown and hit Download Report:

        

    C) Save the report to a secure location (it contains unencrypted information)

…and you’re done!

As you can see, this is a huge pain to clean up duplicative rules/policies/objects/groups, so—going forward—always follow the one rule that would have prevented this whole mess in the first place:

If you already have a hole punched through the firewall for the server/appliance, please just modify the existing rules/policies/objects/groups as opposed to re-running the Public Server Wizard.

You’ll save yourself and others a major headache later on down the road.

Fix: AD Account Keeps Getting Locked Out & Specifying Credentials in DHCP for Dynamic DNS Registration

This was an odd one… we had an account at a client that kept getting locked out and we couldn’t figure out why.

We followed the standard steps to enable Security Auditing for Failure events (which you too can follow if you find that an account is being locked out and Failure Auditing is not enabled (it’s not enabled by default)):

1) Hop onto a Domain Controller

2) Start > Programs > Administrative Tools > Domain Controller Security Policy

3) Match the settings below:

   

4) If you’re feeling frisky, you can force a replication between AD DCs in Active Directory Sites & Services… otherwise, just go get some coffee and wait a bit

5) Start checking the Event Viewer (Start > Run > eventvwr.msc) Security logs for “Failure Audit” events… you can set up a filter if you’d like by going to View > Filter and un-checking everything except for “Failure audit” and using an Event ID of 675:

   

6) Look for event 675s for the account in question… you should see the IP address of the client machine that’s trying to authenticate and failing:

   

If you don’t see any Failure Audits in the Security log of one Domain Controller, try another one!  If the account that’s being locked out is a domain account, it will show up in the Security logs on at least one Domain Controller.

You don’t even have to leave the Domain Controller that you’re on… just right-click “Event Viewer (Local)” and choose “Connect to another computer…” and put in the name of the other Domain Controller(s), searching the Security logs one Domain Controller at a time:

As you can see from the example, we’ve noted that “the call was coming from inside the house” (127.0.0.1) in regards to the failed authentication attempts.  Here’s the full event:

Event Type: Failure Audit

Event Source:     Security

Event Category:   Account Logon

Event ID:   675

Date:       3/24/2011

Time:       [Redacted]

User:       NT AUTHORITY\SYSTEM

Computer:   [Redacted]

Description:

Pre-authentication failed:

      User Name:  admin-[Redacted]

      User ID:          [Redacted]

      Service Name:     krbtgt/[Redacted]

      Pre-Authentication Type:      0x2

      Failure Code:     0x12

      Client Address:   127.0.0.1

…but we couldn’t find any Services, Scheduled Tasks or interactive processes (through Task Manager) that were running with the credentials in question.  Normally, at this point, you would have at least found something that would point you in the right direction—but we couldn’t find anything using the credentials that kept getting locked out.

That’s when we found an Experts Exchange article where someone had mentioned checking “DHCP credentials for DNS dynamic registration.”  Further researching this, we discovered where to set these credentials:

Whoa… whoa… wait a sec here… why would you need to set credentials for the DHCP server to process DNS dynamic registrations?

Full explanation of how to set the credentials here:  http://technet.microsoft.com/en-us/library/cc774834%28WS.10%29.aspx and http://support.microsoft.com/kb/282001

But that still doesn’t explain WHY would this be set this way?!

I mean, seriously… 99.999% of our customers running Windows Server DHCP don’t have this option set!  And sure, they get the occasional 1056 error in their System event log (after every reboot or whenever the DHCP Server service starts up)…

…but why should we worry about this?

From Microsoft KB 282001 http://support.microsoft.com/kb/282001:

The DHCP Server service runs under the domain controller's computer account and therefore has full control of all DNS objects. As a result, DNS records that you have dynamically registered with DNS are susceptible to having their name records overwritten by an earlier version of DHCP Client. This behavior may be undesirable, especially if you have configured the DNS zone for Secure Updates only. By using the DNSCredentials parameter, you can run the DHCP Server service under a specified user account that does not have the ability to overwrite the DNS records.

Microsoft strongly recommends the use of DNSCredentials when you are running the DHCP Server service and DNS services on the same domain controller to ensure the integrity of Secure Dynamic Updates. If you do not use DNSCredentials, Microsoft recommends that you run the services on different computers.

Though I get the gist of what they’re saying here, it was still pretty unclear as to what the tangible security impact would be.  I then stumbled across this post from Shilpesh Desai (a Microsoft employee) posted here: http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/1515eca4-8716-4360-9d40-383145c528ff/ (clipped, emphasis added)

1." Always dynamically update DNS A and PTR records" - Which mean we are asking DHCP to register DNS records on behalf of client machines. As we run DHCP on DC, DHCP will not register records in DNS unless we set credentials (standard user credentials). You can create one user and use his credentials for DNS registration, you don't need to use Admin accounts.

2. instead of above option you can use another option "Dynamically update A and PTR records only if requested by DHCP client machines". If we select this option, client will register A records  and DHCP will register PTR records. We need to set credentials for registering PTR records.

We need to use one of above two options.

3. Dynamically update DNS A and PTR records for DHCP clienst that do not request updates (for example, clients running Windows NT 4.0) - This option can be selected if we have network printers/Downlevel clients (95/98/NT) or third party OS who doesn't have functionality of DDNS. If we uncheck them, mentioned clients will unable to register themselves with DNS.

It's very difficult to crack DC directly as when we prompt server to DC, it enables lot of security. DHCP server mostly interact with clients directly and reason it will be good chance hacker will try to expolit it with melicious discover packet to duplicate IP request, get details about network IP range, etc. He can even use DHCP server service to act as proxy for run remote execution of melicious codes.

if we are using encrypted traffic on network, unknown users will unable to track what traffic we are going through wire.

So, in simpler terms… the as-yet-to-be-determined-where-the-heck-it-is-setting (Hey, look… here it is!  http://support.microsoft.com/kb/816592 (it’s in the DHCP Server or DHCP Scope properties on the DNS tab)) can be updated as follows:

**All of the settings shown above are the defaults for DHCP servers**

“Dynamically update DHS A and PTR records only if requested by the DHCP clients” – default setting – does not require credentials to be set unless the machine requesting the DHCP lease does not request DNS registration, in which case, credentials would be required to allow DHCP to update DNS; however, only clients of the 95/98/NT generation will not request DNS registration

The 2nd highlighted checkbox almost seems redundant, but gets at the same end result.

The Bottom Line                                                               .

As long as you don’t have any 95/98 or NT machines on the network, you do not need to specify credentials for DHCP DNS dynamic registration, and you can safely ignore the error.  If credentials are present, you can remove them without adverse security impact.

Note: I don’t want to get into a huge security argument here… there may still be a small chance that this configuration could cause a problem from a security perspective; however, from a practicality perspective, the hacker would need physical or wireless access to the internal network… at which point, you’ve got bigger problems to deal with.  I suspect that this would be at the very-very-very-bottom of the “penetration test list of things to try” anyway.  Again though, as long as perimeter & wireless security is intact, there’s really nothing to worry about.

Anyway, here’s where to check which credentials are being used:

For Server 2000 & 2003, you need open your DHCP server configuration snap-in (Start > Programs > Administrative Tools > DHCP):

1)  Right-click on the server name and go to Properties:

   

2) Click on the Advanced tab, and hit the “Credentials” button for “DNS dynamic updates registration credentials”:

   

For Server 2008, they’ve actually removed the “Credentials” button under DHCP > right-click [Server Name] > Properties > Advanced tab… but you can check this via the command line.

1) On the DHCP server, you must run cmd as an Administrator (note that it’s not enough simply to be logged on as a Domain Administrator if UAC is enabled):

   

2) Run the command as follows:

    netsh dhcp server show dnscredentials

   

3) If these credentials are not blank, you can zero them out by running the following command:

    netsh dhcp server delete dnscredentials dhcpfullforce

   

This will stop your account from getting locked out, but will result in the occasional 1056 error mentioned earlier (again, not a big deal).