Creepy: Verizon Wireless Is Tracking Your Phone: You Must Opt Out

Verizon Wireless is now tracking your phone, they claim “anonymously,” in the following ways:

• Websites you visit (including search terms)

• Device location

• Device & app usage statistics

• Demographic information (from third parties)

Due to changes in contract terms, you must opt out of this information sharing if you don’t want Big Red tracking you in this fashion.

Here’s the link (you’ll need to log in with your account information):

The full announcement is here:

How To: *CORRECTLY* Redirect Exchange Client Access Servers To The /owa Virtual Directory In IIS

I was recently on the phone with Microsoft support, and they are still very much aware of (and seem to have no plans to fix) the bug in the IIS 7 Manager (Server 2008+) wherein changes at the top “Default Web Site” level tend to propagate to—and overwrite—settings on subfolders:

In more detail, if you decide to use the HTTP Redirect option to redirect the “root” directory to, you will break IIS and OWA unless you then go back and un-check the HTTP Redirect option on the other Exchange virtual directories, including (but not limited to):

·         aspnet_client

·         Autodiscover

·         ecp

·         EWS

·         Microsoft-Server-ActiveSync

·         OAB

·         PowerShell

·         Rpc

(YMMV… these folders are dependent on the version of Exchange)

So, with that glaring bug still present in IIS 7, what’s the Microsoft-approved way to redirect to the /owa Virtual Directory?  I’m glad you asked!

1) Log onto your Exchange server that has the CAS (Client Access Server) role

2) Fire up the “Internet Information Services (IIS) Manager”:


3) Expand down the tree until you can highlight “Default Web Site,” then click the “Content View” button:


    SIDEBAR: Do NOT rename the “Default Web Site”… things will break until you change it back!

4) Right-click a blank area and choose “Explore” from the menu:


5) Right-click in a blank area in the (by default) C:\inetpub\wwwroot directory and choose “New > Text Document”:


6) Type in the following code (though this is purely cosmetic and strictly unnecessary… the file could be blank and it would still work… it’s just helpful if someone is coming in behind you and doesn’t understand how the redirect is actually working):



<title>Redirecting to /owa...</title>



Redirecting to /owa using a HTTP Redirect added to this index.html document in IIS Manager’s Content View...



7) Save the file as “index.html” (with quotes so that the file extension remains intact) in the (default) C:\inetpub\wwwroot directory:


8) Close notepad and return to IIS Manager

9) Highlight your new “index.html” file (you may have to Refresh the screen before you can see it), then right-click on the file and choose “Switch to Features View”:


10) You’ll now see “index.html” under the “Default Web Site” tree… highlight it and choose “HTTP Redirect” from the right-hand pane:


11) Put in the full URL for OWA (including HTTPS, assuming you have a certificate installed) and check the boxes for “Redirect requests…” and “Only redirect requests…” with a status code of “Found (302)”:


12) Highlight “Default Web Site” and double-click on “Default Document”:


13) Highlight “index.html” and click “Move Up” in the Actions pane until it’s at the top of the list:


14) You’re done!  Test it out by going to (or whatever your OWA URL is)

Fix: Outlook 2007/2010 Out-Of-Office and Free/Busy Data Not Working

This is a rather obscure one and requires a very limited set of circumstances for this problem to affect your clients in this way; however, I believe it’s worth noting:

Base Assumptions

·         You’ve already properly configured the Exchange service URLs

o    Exchange 2007:

o    Exchange 2010:

·         A few (or even a good percentage) of your users are having difficulty setting their Out-Of-Office messages or viewing the Free/Busy scheduling data when scheduling calendar appointments

·         You have, at one point in time, used the Microsoft Online Services Sign In client application in order to get folks connected up to Microsoft’s BPOS solution


As alluded to above, you’ll receive the following error messages when attempting to set your Out-Of-Office:

“Your automatic reply settings cannot be displayed because the server is currently unavailable.  Try again later.”

…or when you try to view the Free/Busy data on other calendars (other people and/or resources/rooms):

“No free/busy information could be retrieved.  Your server location could not be determined.  Contact your administrator.”

If you hold down the Ctrl key and right-click on the Outlook icon, you can “Test E-Mail AutoConfiguration…”:

…and when you un-check “Use Guessmart” and “Secure Guessmart Authentication” and hit the “Test” button, you’ll get the “Autoconfiguration was unable to determine your settings!” error message shown below:

Please note that the standard setup process of creating a new Outlook profile will work without issue; however, it’s only after you set up the profile that Autodiscover (and, by extension, the Exchange Web Services and/or Availability Service) goes to hell in a handbasket.

Root Cause

The following registry entries are the cause of the issue:









What these registry entries are effectively doing is telling Outlook to “not even try” Autodiscover, and to instead prefer a local XML file to tell it how to connect to your Exchange server.

You’ll definitely notice this if you do a two-sided packet capture on a “problem” machine and the Exchange server simultaneously while running the “Test E-Mail AutoConfiguration…” utility—there will not be any traffic from the Outlook client on the “problem” machine to the Exchange server or any of the usual autodiscover URLs.  That’s because the registry entries above are preventing Outlook from even going out to check those URLs.

So, you might be asking yourself, “Well, how in the name of Chuck Norris did those get there?”

The answer is: the Microsoft Online Services Sign In client application… you know, this guy:

Let’s check the registry branch before I use the Microsoft Online Services Sign In client application to configure a new Outlook profile to connect to BPOS:

(there are others listed, these are just a sample)

Notice that all keys/values are of type “REG_SZ” (string values) and point to various XML files in the following directories:

·         Office 2007: C:\PROGRA~1\MICROS~1\Office12\OUTLOO~1\

·         Office 2010: C:\PROGRA~1\MICROS~1\Office14\OUTLOO~1\

Again, prior to using the Microsoft Online Services Sign In client application to configure Outlook, there are no REG_DWORD values in this registry branch.

Now let’s use the utility to configure Outlook.  If you’re doing this the first time (i.e. you’re just installing the client application), this will be done automatically.  If you ever need to go back and re-do this step, you can do it from Options > Advanced Options > “Reconfigure my desktop applications”:

You’ll select only Outlook and click the “Configure applications” button (you will have to exit Outlook):

…and once that’s done, presto-change-o, you have some shiny new REG_DWORD values like the ones I listed earlier:

You’ll also notice another shiny new REG_SZ value for


Just for giggles, let’s look at what’s in this XML file:

So, it would appear that Microsoft is “hedging their bets” in regards to how autodiscover actually works, even though I have no idea why they would need to do this, seeing as though they already have a CNAME record for that gets me to the right place:

After working with Microsoft support, they referenced a cached (read: suspiciously deleted from the KB) article that addresses these exact registry entries.  Why this KB article was removed I’m not sure.  See the attached PDF for the full article, but the key parts are detailed here (emphasis added):

Consider the following scenario:

o    The e-mail environment in your organization uses the following programs:

§  Microsoft Exchange Online

§  Microsoft Exchange Server 2007

§  Microsoft Office Outlook 2007

o    You have a mailbox in Exchange Online and a mailbox in Exchange Server 2007.

o    You have the same primary Simple Mail Transfer Protocol (SMTP) e-mail address in Exchange Online and in Exchange Server 2007.

In this scenario, you experience the following issues:

·         The AutoDiscover feature that Outlook 2007 uses does not configure Outlook 2007 for the Exchange Online environment.

·         The AutoDiscover feature reverts back to Exchange Server 2007. Additionally, you cannot access e-mail when you use the Outlook 2007 client.

Note: These issues usually occur during the Exchange Online trial period or during an e-mail coexistence period between Exchange Online and Exchange Server 2007. When the Exchange Server 2007 mailbox that you use is fully migrated to the Exchange Online environment, the Exchange Server 2007 mailbox is deleted.

Interestingly, after checking our partner BPOS account (, I see that neither our primary SMTP domain nor my personal address have our actual domain set as primary… instead, my primary domain is

…and here’s my user account:

So that still begs the question, “Why would Microsoft change the registry entries when I use the client application if my e-mail domain in BPOS ( isn’t the same as my actual primary SMTP domain on my Exchange server (”

I decided to look for a newer version of the client application… as we can see, I’m running version 1.0.1427.0040, and the latest available is 1.0.1442.000 released on 4/25/2011 (at the time of writing).  The download page for the newest version is located here:

So, I tried an experiment.  I deleted the “REG_DWORD” keys from the registry branch mentioned earlier (HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover), uninstalled the old client application, installed the new client application, and attempted to have it configure Outlook once again.

Surrrrrveyyyy says:

Dear Microsoft,

So, I reckon that this will continue to be an issue for as long as we continue to use the Microsoft Online Services Sign In client application.  Hooray!

The Quick-N-Dirty Fix

Because the registry entries are in HKEY_CURRENT_USER, I can’t easily update these en-masse using our centralized management system, as the HKEY_CURRENT_USER designation is dependent upon who is logged in at the time.

The quickest way to fix this, I’ve found, is to add the following lines to all of the necessary logon scripts (which run in the correct user context of the currently logged on user):

@echo off


echo Deleting errant registry entries that prevent Autodiscover functionality...


echo Office 2010...

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v PreferLocalXML /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeHttpRedirect /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeHttpsAutodiscoverDomain /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeHttpsRootDomain /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeScpLookup /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeSrvLookup /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeSrvRecord /f


echo Office 2007...

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v PreferLocalXML /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeHttpRedirect /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeHttpsAutodiscoverDomain /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeHttpsRootDomain /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeScpLookup /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeSrvLookup /f

reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeSrvRecord /f


echo Errant registry keys (if they exist) have been deleted!


It appears that the registry entries, once deleted, remain deleted until such time that the user chooses to “Reconfigure my desktop applications” (again, per the screenshot below):

So this is definitely something to be aware of… if a user installs the client application and can no longer access his/her Out-Of-Office settings and his/her Free/Busy data, and assuming that you’ve added the aforementioned lines to everybody’s logon script, just tell him/her to log off and log back on again and the problem should be fixed.

For the record, I’m leaving this as part of everybody’s logon script until we’ve transitioned our partner account to Office 365. :-)

How To: Allow Standard Users To Join Computers to Your Internal Domain

By default, an authenticated user can join up to 10 computers to a domain.  Once they exceed 10 machines, (s)he will no longer be able to add any more computers to the domain.  Ever.  Neat!

So, in order to allow key users/groups to add computers to the domain, you’ll need to do the following:

1) Hop on an AD domain controller

2) Bring up “Active Directory Users and Computers” (Start > Run > dsa.msc)

3) Right-click on your domain and choose :Delegate Control…”:


4) Hit Next on the welcome screen and hit the Add button to add the users and groups you need, and then hit Next again:


5) Chick the box for “Join a computer to the domain” and hit Next:


6) Hit Finish to complete the wizard

7) Now you’ll need to remove the 10-item-limit… open ADSI Edit (Start > Run > adsiedit.msc)

8) Expand the tree until you see your domain… right-click on it and choose Properties:


9) Scroll down until you find the “ms-DS-MachineAccountQuota” item and click Edit:


10) Click the Clear button, hit OK, hit OK again, and close ADSI Edit:


This should make it so that selected users & groups can join computers to the domain without running up against the 10-item-limit.

How To: Add A Domain Group To The Local Administrators Group On A Domain Controller

There are a very limited number of circumstances when you’d want to do this, most of which are boring & technical (e.g. adding an Exchange 2010 Database Availability Group and using a “Witness Server” of one of your Domain Controllers requires that the “Exchange Trusted Subsystem” domain group be added to the Local Administrators group on the Domain Controller itself)… but here goes anyway…

You’ll notice that if you use a “net localgroup administrators /add DOMAIN\Group” that the command fails with a syntax error.  Some folks say that this is because of a limitation on the length of the group name, but I call shenanigans on that explanation.  At any rate, you’ll slam your head against your desk for a while, until you do the following:

1) Open up Notepad

2) Paste in the following lines, substituting [DOMAINNAME] and [DOMAINGROUPNAME] as necessary:

Set objLocalGroup = GetObject("WinNT://./Administrators")



Set objLocalGroup = Nothing

Set objADGroup = Nothing

3) Go to File > Save As, and save it on your Desktop as “script.vbs”

4) Go to Start and type in cmd, then right-click on cmd and choose “Run as Administrator”:


5) CD to your Desktop and then run the command: “cscript script.vbs” as in the example below, and once the script runs, do a “net localgroup administrators” to verify that the script added the requested group properly:


As you can see, the script works :-)