Bob's questions

I'm looking at a default Defender configuration in Server 2016. I'm not sure how to discover what these '0' mean for the ThreatDefaultAction:

HighThreatDefaultAction                       : 0
LowThreatDefaultAction                        : 0
MAPSReporting                                 : 2
ModerateThreatDefaultAction                   : 0

I would think from the Set-MpPreference documentation that it's Quarantine, but that same bit of text references a Parameter set that starts with 'Clean', not 'Quarantine'. This explanation of ThreatIdDefaultActions doesn't even have a 0 in it's list: Add-MpPreference

I'm looking at a Physical Disk\Avg. Disk sec/Transfer counter in perfmon. We've always had faith in the Average number that perfmon reports over the selected time span.

I can't figure out why if I use perfmon to save the data to .csv, or relog the whole blg to .csv the number calculated by '=Average(A:A)' in excel is wildly different than the number reported in the tool. Several people seem to have asked this question in various forums over the years, but I see no answers. Specifically, the Average Avg. Disk sec/Transfer as reported in the perfmon tool is .041, but =AVERAGE(SY:SY) (this is the SY column that contains this data, PhysicalDisk(2 T:)\Avg. Disk sec/Transfer) returns 0.008787746. That's not even in the same ballpark. I even tried an AverageIf to exclude columns with a value of 0...barely makes a difference.

BTW - The counters are being recorded on a Server 2003 32bit machine and analyzed on a Win 7 64 bit machine.

Any ideas?

Is there an ADUC setting that can prevent certain user accounts from locking out, particularly after x number of failed logon attempts? Oh and our DC is on Server 2003 at the moment, but we also use Server 2008 DC's in other environments.

First time going through this scenario, and apparently I did it very wrong. On the DB servers I deleted the cluster group that held SQL and Reporting Services. I then destroyed the cluster. Then I tried to uninstall SQL. No dice. SQL still thinks its part of the non-existant cluster and will not let me uninstall it. I went into the Maintenance menu of the SQL setup and tried to Remove Node...nope.

Unless I find a way out of this I will have to rebuild the OS if I can't get SQL off the box.

Posted this on StackOverflow, but I think it's probably more germane to this crowd.

I am having an issue with sending a MSMQ message to the second DNS name on a server. If we send the IP for that same server, we're fine, but that's not where we are going architecturally. Any ideas as to why MSMQ would care about which name it receives?

Here is our example:

Server Information: The physical server load-int-01, has a second IP and DNS name associated with it. First IP/DNS: load-int-01, with IP 10.0.10.10 Second IP/DNS: load-intv, with IP 10.0.10.20

Queue path formats used:

FormatName:DIRECT=OS:load-int-01\private$\MyQueue -> Works Fine

FormatName:DIRECT=OS:load-intv\private$\MyQueue -> Returns the following error:

The queue does not exist or you do not have sufficient permissions to perform this operation

We have also tried using the IP addresses instead, and both sets of IPs work fine.

FormatName:DIRECT=TCP:10.0.10.10\private$\MyQueue -> Works Fine FormatName:DIRECT=TCP:10.0.10.20\private$\MyQueue -> Works Fine