$ssa = Get-SPEnterpriseSearchServiceApplication

$cl = New-Object Microsoft.Office.Server.Search.Administration.CrawlLog $ssa

$cl.GetCrawledUrls($false,1000000,"",$false,-1,0,-1,[datetime]::minvalue,[datetime]::maxvalue) | export-csv -notype successes.csv  # This will likely be huge

$cl.GetCrawledUrls($false,1000000,"",$false,-1,1,-1,[datetime]::minvalue,[datetime]::maxvalue) | export-csv -notype warnings.csv

$cl.GetCrawledUrls($false,1000000,"",$false,-1,2,-1,[datetime]::minvalue,[datetime]::maxvalue) | export-csv -notype errors.csv

Then just a quick ETL to SQL for SP's index, a full outer join and done.

Hardening SQL Server is done in a 3 phased approach:

1. Encryption at Rest (Encrypt the data sitting on the hard drives)
2. Encrypt Connections (Encrypt the data in flight on the network between servers)
3. Server Isolation (Configure SQL Server's firewall to ignore requests from unauthorized servers)

NOTE: These steps are done on a single server instance. This blog can be used as a guide for more complex implementations including other firewall products, clustering, IPSec, VLANs, etc. Additionally, this post assumes you've already implemented Kerberos.

Encryption at Rest

Encryption at Rest is accomplished via Transparent Data Encryption (TDE). TDE uses a server level certificate to do page level encryption on the raw database MDF/LDF files. TDE uses a symmetric key stored in the master database in the form of a certificate (or an asymmetric key stored in an EKM module, but that's beyond the scope of this discussion). Data is encrypted in AES or 3DES and the original certificate is required to access the database.

At a high level, TDE protects us in the event the hard drives or backups are stolen/compromised; the offending user will not be able to restore or attach the databases. SQL Server recovery tools will be nullified and only recover gibberish. If users are unfamiliar with the concept, TDE is logically similar to Bitlocker in the OS.

How to set it up:

TDE is deployed in 2 phases: Instance and Database Configuration. Instance Configuration is done only once per instance, but Database Configuration will need to be repeated for each database

Instance Configuration:

1. Create a master key (and Password!) that will reside in the Master Database

   USE [master]

   GO

   CREATE MASTER KEY ENCRYPTION BY PASSWORD='P@$$w0rd'

   GO

    

2. Create a certificate protected with the Master Key

   USE [master]

   CREATE CERTIFICATE TDECertificate WITH SUBJECT = 'TDE Certificate'

   GO

    

3. Done!

    

Database Configuration:

1. Get the certificate name

   SELECT name,pvt_key_encryption_type_desc FROM sys.certificates

   GO

    

   

    

2. Create a Database Encryption Key (I created a DB called "Test") using the certificate name from the previous step

   USE [Test]

   GO

   CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256

   ENCRYPTION BY SERVER CERTIFICATE TDECertificate

   GO

    

3. Set the Database to use Encryption

   USE [master]

   ALTER DATABASE [Test] SET ENCRYPTION ON

    

4. Done!

Backup the Cert:

1. You'll need the cert to restore the DB to another server. Back up both files and save the Encryption password somewhere secure!

   BACKUP CERTIFICATE TDECertificate

   TO FILE = 'C:\TDECertificate.cert'

   WITH PRIVATE KEY ( FILE = 'C:\TDECertPrivateKey.key', ENCRYPTION BY PASSWORD = 'P@$$w0rd1234')

   GO

    

2. Done!

Test:

1. Backup the database

   BACKUP DATABASE [Test]

   TO DISK='C:\Test.bak'

   GO

2. File copy it another instance (Instance B) and try to restore it

   RESTORE DATABASE [Test]

   FROM DISK='C:\Test.bak'

   GO

3. It will fail with a message similar to

   Msg 33111, Level 16, State 3, Line 1
   Cannot find server certificate with thumbprint '…….'.
   Msg 3013, Level 16, State 1, Line 1
   RESTORE DATABASE is terminating abnormally.

4. Success! Users can not arbitrarily restore the database without the applicable certificates from the server and the encryption password
5. To properly restore the database, file copy the C:\TDECertPrivateKey.key file to Instance B and restore it

   USE master

   CREATE CERTIFICATE TDECertificate

   FROM FILE = 'C:\TDECertificate.cert'

   WITH PRIVATE KEY (FILE = 'C:\TDECertPrivateKey.key',

   DECRYPTION BY PASSWORD = 'P@$$w0rd1234')

   GO

6. Try to restore the database on Instance B

   RESTORE DATABASE [Test]

   FROM DISK='C:\Test.bak'

   GO

7. Done!

That finalizes our TDE setup and encrypts our data on the disks. We're now protected from individuals grabbing the disks and/or database backups without authorization.

Note about Compression: Compression is done by finding patterns in the binary format of the applicable file and converting them to a smaller pattern (i.e. '12345' is represented by 'a'). Encryption removes patterns in the raw data to prevent brute force decryption. Compression and Encryption do not coexist and TDE will effectively eliminate all gains from Compression. Enabling encryption on a compressed database will just cause a lot of useless overhead as SQL decompresses an uncompressed file.

Encrypt Connections

Encrypting the Connections is accomplished via Secure Socket Layer (SSL). SSL uses a certificate exchange process to validate the server's authenticity and encrypt the data exchanged between the servers.

SSL protects the environment by encrypting the information transmitted between servers. If a malicious user was attempting reconnaissance via a wire sniffer (Netmon, WireShark or some similar tool) all the data would be encrypted and the user would get gibberish.

How to set it up:

Note: This walkthrough assumes you've already deployed an applicable server certificate. My VM uses a self-signed cert; a full production configuration should use a 3^rd party trusted authority.

1. Open Sql Server Configuration Manager
2. Expand SQL Server Network Configuration
3. Right click on Protocols for <Instance Name> and select Properties

   

    

4. Change Force Encryption to Yes

   

    

5. Select the Certificates tab and select your applicable certificate

   

    

6. Click OK and restart SQL Server
7. Done!

Test:

1. Execute the below command and validate Encrypt_Option is set to TRUE

   SELECT net_transport, auth_scheme, encrypt_option

   FROM sys.dm_exec_connections

   WHERE session_id = @@SPID;

    

2. Done!

Note: Authentication to SQL Server via NTLM/Kerberos is ALWAYS encrypted. But transactions after encryption are clear text

Server Isolation

Server Isolation can be done several different ways, but the end result is the same: configuring the server to only respond to authorized machines. An "authorized machine" is a list controlled by a governing body (usually security team or network team). The simplest and most cost effective way to isolate SQL is configuring the Windows Firewall with Advanced Security. Other methods exist (VLANs, other Firewall products, etc.) but they are beyond the scope of this document.

By isolating SQL, we reduce the attackable area of SQL server, enforcing an additional layer of security beyond network access.

How to set it up:

Note: This walkthrough configures the local machine's firewall. Windows Firewall is configurable via Group Policy and should be used if you're deploying an actual production environment.

1. Windows Firewall with Advanced Security from Administrative Tools
2. Verify Inbound Connections that do not match a rule are blocked

   

    

3. Select Inbound Rules and choose New Rule
4. For Rule Type select Program and click Next
5. Select your SQL Server EXE and click Next
   1. Default path is C:\Program Files\Microsoft SQL Server\<Instance Name>\MSSQL\Binn\sqlservr.exe
6. Choose Allow the Connection and click Next
7. Choose all 3 domain types and click Next
8. Give the new rule a Friendly Name and click Finish
9. Select your newly created rule and select Properties

   

    

10. In the Test properties window, select Scope tab and change Remote IP Address to These IP Addresses

    

     

11. Click Add and add all IP Addresses of the SharePoint Farm

    

     

12. Click OK to close the window
13. Done!

Test:

1. From an authorized machine (one of the IPs you put in the previous step), open SQL Server Management Studio and try to connect. It should be successful.
2. From an unauthorized machine (an IP you didn't put in the previous step), open SQL Server Management Studio and try to connect. It should fail

   

3. Done!

Summary

SQL Server's security should match the information sensitivity in SharePoint. SharePoint/Windows permissions do not apply to raw content within the database and are insufficient to protect SharePoint's data to a determined user. There is a cost associated with each security implementation, both in server performance and O&M. Your mileage may vary, but my load tests showed +/- 15% performance degradation. However, if security if your primary concern, these performance costs could be mitigated by scaling up SQL Server.

While no amount of security is perfect, implementing this three phased approach will significantly reduce SQL's vulnerability to unintended data access.

Further reading with a deeper analysis of these security approaches and additional information for Access Control can be found on the whitepaper SQL Server 2012 Security Best Practices - Operational and Administrative Tasks

Non-Default Ports and SQL Client Aliases

Non-Default Ports + SQL Client Aliases are obfuscation and should not be used as a sole defense strategy. With regards to security, a Non-Default Ports implementation is limited when considering the ease and speed of current technology to scan the ~65k possible ports SQL Server could utilize. SharePoint requires SQL Aliases in all Non-default port SQL instances, but SQL Aliases are incompatible with some business intelligence features and Diagnostic Timer Jobs. Returning SharePoint to 100% functionality requires a combination of SQL Client aliases and DNS Aliases. SQL-specific traffic will use the SQL Client alias, while non-SQL Traffic to the database server (i.e. WMI calls) will utilize the DNS Alias.

Consider the limited value of Non-Default port implementations, compared to the operational complexity of SQL Client Aliases and DNS Aliases before implementing. Additionally, there is no security value using SQL Client Aliases in default port implementations.

DNS Aliases

DNS Aliases facilitate scale up/scale out/migration scenarios and enhance manageability. Their value is concentrated in maintenance activities and bring little value to a defense strategy. Their use is 100% compatible with all SharePoint functions and features.

"Instead of consolidating application pools, how do I split up an application pool with too many web applications?"

The answer is actually to modify the application pool properties of the Web Application; NOT create a new application pool and set the Web Application Property. Here's the code:

$webApp = Get-SPWebApplication https://sp2013.lab.local
				

$newWebAppPWD = ConvertTo-SecureString "Password"

$webApp.ApplicationPool.Username = "lab\AppPoolSvcAcct"

$webApp.ApplicationPool.Name = "New App Pool Name"

$webApp.ApplicationPool.SetPassword($webWebAppPWD)

$webApp.Provision()

To check your work:

$appPools = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.ApplicationPools

$appPools

First, from SharePoint 2007, execute the PowerShell:

ststadm -o enumallwebs -includewebparts -includefeatures -databasename WSS_Content_YourDBName > sp2007EnumWebsOutput.txt 

This command essentially lists every web in your database and the features and webparts it's using. Compare that list with a known list of out-of-box (OOB) features and the deltas will be the customizations. I wrapped that up into a TSQL command the creates a nice pivot table with webs and customizations. To use it, copy the sp2007EnumWebsOut.txt to an instance of SQL Server and execute the attached TSQL (attached).  The result with be 3 SQL Results with the source of the features listed (OOB, Fab40 or Custom). Copy and paste those to Excel and you can do whatever filtering and sorting you need to identify the sites.

Identify Customizations sql.txt

Why is this a problem? Consider the most basic SharePoint architecture with a single Web Application:

This architecture uses 4 IP address: 1 for the VIP and 3 for the Web Front Ends. Next, you've followed the Best practices for My Sites article, and deployed MySites to a dedicated Web Application and you require SSL. Your architecture is now:

The IP footprint has grown from 4 to 8. If we added another web application requiring SSL, this would need a total of 12 IP addresses and there-in lines our scalability problem: In SharePoint on IIS 7.5 (Windows 2008 R2), the traditional IP address footprint is calculated with the formula

(Number of Web Servers + Number of Network Load Balancer Devices) * Number of Web Applications

A bigger, hypothetical network of 5 servers, 3 web applications and 1 NLB, your IP footprint would be a whopping 18 IP Addresses! In a non-SSL environment, you would just configure hostnames, but when you try to select the certificate in IIS 7.5, the hostname header gets grayed out:

So, what do we do? NetSH.exe! With NetSH, we can tell the machine to "encrypt traffic on <x> port with <y> certificate". Combine it with a wildcard certificate and all IIS traffic will be encrypted with the port, but you can still use hostnames. To execute, from an elevated command prompt, execute:

Certutil –store My

Location the applicable certificate on the output and notate the hash value (we're going to need it!). My hash is b063314fab008a45b5a1afb0f0dee45b59eb2584

Now execute the NETSH command:

netsh http add sslcert ipport=0.0.0.0:443 

certhash=b063314fab008a45b5a1afb0f0dee45b59eb2584 

appid={00112233-4455-6677-8899-AABBCCDDEEFF}

The command's breakdown:

add sslcert is self-explanatory

ipport=0.0.0.0:443

certhash=b063314fab008a45b5a1afb0f0dee45b59eb2584

appid={00112233-4455-6677-8899-AABBCCDDEEFF}

Or to summarize "Encrypt all traffic on port 443 with this cert".

Now we can create a web application in SharePoint, choosing an applicable host header and port 443:

Create your site collection and browse it. Pull up the Certificate and wala! You've had the certificate applied (Note, I did NOT go into IIS and choose the certificate!).

This approach only works if you have one-and-only-one certificate per server, usually in an extranet/intranet environment. In a hosting environment, this may not be applicable unless all your sites are sharing an SSL certificate.

Question: Isn't this Server Name Indication, newly available in Windows 2012 / IIS8?

Answer: No. SNI is a many (certificates)-to-many (sites) solution. IIS7.5 cannot do SNI, but SNI can fulfill the same user scenario of this approach. If you're running Windows 2012, use SNI. If you're on Windows 2008 R2, use the above approach.

Question #2: I'm using dedicated IPs and want to switch to this approach. How do I do it?

Answer: If you have sites currently using 443, netsh will give you an error. To fix it, you need to remove all your 443 bindings and re-add them without certificates. If you use the IIS Admin GUI to do it:

1. Change the current port 443 binding to a new port (4433 for example)
2. Create a new binding on 443 with the specified hostname (but do not select a certificate!)
3. Delete the 4433 binding and proceed with your netsh commands

As an alternative, you could use APPCMD or PowerShell to do the same thing; the end result is what's needed: no bindings on 443 with specified certificates.

Obligatory warning…here comes the deep dive!

There are several fields in users' profile that leverage the MMS service. Out of box, these include the Past Projects, Skills and Schools fields:

These are free text fields and are used for a better search and social experience. Leveraging UPS and MMS, users can identify all users with a particular skill set, or past alumni. You can see all the terms that have been created by going to the Term Store Management:

In the database, we can see the terms association across the MMS and UPS Profile databases:

Note: Do not run these on your production environment; they are only here to show the closely related the IDs and Terms across the databases. Even with NOLOCK, it can affect the farm and put you in an unsupported state. I crashed my MMS Service while getting these screenshots because of these queries

We can see the same tight association when we use an MMS column in a list in the content databases:

And in the database:

Note: Do not run these on your production environment; they are only here to show the closely related the IDs and Terms across the databases. Even with NOLOCK, it can affect the farm and put you in an unsupported state. I crashed my MMS Service while getting these screenshots because of these queries

The Managed Metadata Service application uses the GUID and TermID fields to provide all MMS functionality. The column value is added for the end user to view without the need of another join on the list item. Keeping the Managed Metadata Service's Database, the Content Database and the User Profile's Profile Database in sync is required for proper functionality of the environment.

If databases get out of sync, you'll have mixed results when using any MMS driven fields. Some of the symptoms you'll see are: the MMS fields are read/only (it's relying on the column value to populate for the end user instead of using the ID), all MMS driven functionality will cease (workflows, content type logic, etc.). Search will start acting up when crawling users, social tagging/notes will fail intermittently and other issues will manifest.

The real problem is that you won't know this is happening until you try and use the secondary farm! Think about that for a moment: your primary farm is offline, the secondary farm is brought online and large components of the farms are inoperable. THAT will not be a fun day.

<< Obligatory warning over >>

The UPRE Gap: (Spoiler – UPRE is unreliable if the MMS Database is Read/Only)

The key to a viable standby farm requires that the Profile Database, the Managed Metadata Database and the Content database are in sync. Until recently, the only way to accomplish a standby farm was to log ship the Content and MMS databases, but use UPRE for the Profiles. This kept the Content and MMS databases in sync, but Profiles (UPS) was in a constant state of flux. Consider these scenarios:

1. Scenario: MMS log is applied during UPRE run
   1. Outcome: all updates for that run would fail as UPRE would not be able to access the MMS Database.
2. Scenario: a user adds a new MMS term to their profile and UPRE ran before the MMS log ship
   1. UPRE will try to add the MMS term at the destination farm and fail due to the database being in Read-Only (because of log shipping)

Traditionally, the answer has included some kind of timing solution and ignoring the UPRE errors that occur in the second scenario. But this isn't a true hot standby; a large portion of your farm (profiles) are in a state of flux, you can't be sure of their current state. If the hot standby has an RTO/RPO of less than an hour, but you've implemented a timing solution (for example, UPRE run every 24 hours and MMS log updates are paused) then you've already missed your RTO/RPO SLAs by your own design!

How to choose when to UPRE and when to Log Ship:

The decision to UPRE or to Log Ship the Profile and Social databases is influenced by several factors: Volume of Social Data, RPO/RTO, Disaster Recovery you're leveraging (Hot/Warm/Cold). To guide the decision, we have to ask several questions:

1. How are we using the secondary farm?
   1. Is it a Hot Standby? Or another active farm that needs Profile information?
2. (Assuming it's a Hot Standby) What is the RPO and RTO times for the secondary farm?
3. (Assuming it's a Hot Standby) Is there a difference in timing between UPRE and Log Shipping?
   1. Can both UPRE and Log Shipping complete within the RPO and RTO window?
4. How critical are User Profiles? Are they deemed critical enough to have the same uptime and availability as the content databases?
5. What is the state of the secondary farm's MMS Database (read-write or read-only)?

Answering these questions will quickly favor UPRE or Log Shipping. Consider these two scenarios:

Scenario A:

Consider you have 2 regional farms deployed, one in London and one in Seattle. Both farms are serving content to users, but Profiles from Seattle Farm are needed at the London Farm. The answers to our questions are as follows:

1. How are we using the secondary farm? Another active Farm that needs Profile information
2. (Assuming it's a Hot Standby) What is the RPO and RTO times for the secondary farm? N/A – it's not a Hot Standby
3. (Assuming it's a Hot Standby) Is there a difference in timing between UPRE and Log Shipping? N/A – it's not a Hot Standby
   1. Can both UPRE and Log Shipping complete within the RPO and RTO window? N/A – it's not a Hot Standby
4. How critical are User Profiles? Are they deemed critical enough to have the same uptime and availability as the content databases? No
5. What is the state of the secondary farm's MMS Database (read-write or read-only)? Read-Write

Since the London Farm's MMS database is Read/Write and is an active farm requiring profile information from Seattle Farm, UPRE would be our choice. UPRE would be able to add terms to the MMS Database and would not be susceptible to disconnection of a log restore of the MMS database.

Note: this is NOT a DR/Hot-Standby solution. This is merely two farms that hold separate information, but the London Farm needs the Seattle Farm's profiles for a business need.

Scenario B:

Consider the same 2 regional farms deployment, a farm in London and a farm in Seattle. All users access the Seattle Farm; the London farm is used if the Seattle farm is unavailable due to maintenance or downtime. The answers to our questions are as follows:

1. How are we using the secondary farm? Hot-Standby
2. (Assuming it's a Hot Standby) What is the RPO and RTO times for the secondary farm? 45 minutes and 30 minutes
3. (Assuming it's a Hot Standby) Is there a difference in timing between UPRE and Log Shipping? No difference in timing between UPRE and Log Shipping
   1. Can both UPRE and Log Shipping complete within the RPO and RTO window? Yes
4. How critical are User Profiles? Are they deemed critical enough to have the same uptime and availability as the content databases? Yes
5. What is the state of the secondary farm's MMS Database (read-write or read-only)? Read-Only

Since the London Farm's MMS database is Read/Only and is Hot-Standby of the Seattle Farm, Log Shipping the Profile and Social databases would be our choice. Log Shipping allows us to have a consistent point-in-time on the secondary farm without being affected by the database disconnects that would plague UPRE in this same scenario.

Note: this is a DR/Hot-Standby solution. Seattle Farm is log shipping all the content, MMS and UPS databases to the London farm.

Note: it's critical that your databases (Content, MMS, Profile and Social) are all in sync in this scenario. Make sure the timing on your SQL Agent Jobs all match!

Is there ever a time to use UPRE instead of Log Shipping in a Hot Standby?

Absolutely! Here are a few scenarios where UPRE could be chosen instead of Log Shipping:

• UPRE gives us the flexibility to pick and choose specific profile fields to synchronize and Log Shipping is all or nothing. If there was a business or security need to reduce the properties to a smaller subset, then UPRE would be a better decision.
• If we are space constrained on the secondary farm, UPRE would be a better decision; log shipping requires more space on the secondary farm to hold the backup of the transaction log.
• If the 3 SQL Agent Jobs associated with Log Shipping exceed the RTO/RPO SLAs, UPRE would be the better decision
  • This can happen if you are heavily using SharePoint's social features.

Summary:

With the option to Log Ship the Profile and Social databases, we have greater flexibility to meet the business' needs to provide a reliable and consistent user experience. Choosing when to Log Ship and when to UPRE, as well as the pros and cons of each, is critical to ensure your architecture is working as expected.

I was working with Russ today and an interesting question came up:  If a user had a list with a multivalue column, how do we find all the list items with more than 1 value selected?

After much trial and error, LINQ was the simplest to implement.  Here's the list we used:

Testcol is a multi value column and thus our expected result was to return the Recipe #2 and Recipe #4 items.  Returning #3 or #1 was a fail.

On the backend, SharePoint splits it's values with a #; combination.  We can see this using the u2u CAML builder:

So the resultant code was a LINQ query with a split on the ;# values:

using (SPSite oSite = new SPSite("https://VM-SP2010/"))

            {

               using (SPWeb oWeb = oSite.RootWeb)

                {
           SPList oList = oWeb.Lists["TestList"];

                  List<SPListItem> items = (from l in oList.Items.OfType<SPListItem>() where l["Testcol"].ToString().Split(new[] { ";#" }, StringSplitOptions.None).Length > 3 select l).ToList<SPListItem>();

                  foreach (SPListItem item in items)

                    {

                     Console.WriteLine(item.DisplayName);

                    }

                }

            }

           Console.WriteLine("All done!");

           Console.ReadLine();

And the final result:

To validate, I started WireShark and made an nslookup DNS request.  Sure enough, VM-DC got the request first, returned back a bad hostname and then my normal DNS server got the request.  From there, I went to make sure my DNS entry didn't get into my External NIC configuration:

Ethernet adapter vEthernet (External LAN):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   Physical Address. . . . . . . . . : D0-67-E5-38-18-8C
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::c0c1:ae76:bdbe:5c9e%19(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.10.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, June 11, 2012 12:09:00 PM
   Lease Expires . . . . . . . . . . : Tuesday, June 19, 2012 12:08:59 PM
   Default Gateway . . . . . . . . . : 192.168.10.254
   DHCP Server . . . . . . . . . . . : 192.168.10.254
   DHCPv6 IAID . . . . . . . . . . . : 399534053
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-17-5A-B2-7C-D0-67-E5-38-18-8C
   DNS Servers . . . . . . . . . . . : 192.168.10.254
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter vEthernet (External WiFi):

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : gateway.2wire.net
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
   Physical Address. . . . . . . . . : 00-24-D7-C8-20-34
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Ethernet adapter vEthernet (Internal LAN):

   Connection-specific DNS Suffix  . : VM.local
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #4
   Physical Address. . . . . . . . . : 00-15-5D-01-4C-00
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::2c1d:8047:d6a:f39b%21(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.250.101(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, June 11, 2012 1:19:24 PM
   Lease Expires . . . . . . . . . . : Tuesday, June 19, 2012 1:19:23 PM
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . : 192.168.250.1
   DHCPv6 IAID . . . . . . . . . . . : 805311837
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-17-5A-B2-7C-D0-67-E5-38-18-8C
   DNS Servers . . . . . . . . . . . : 192.168.250.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

As you can see, VM-DC (192.168.250.1) is definitely not on my External LAN NIC.  So why is it still getting the initial DNS request?  Next I went into the Network Adapters, hit ALT, looked at the binding settings and EUREKA:  my Internal LAN NIC was listed before my External LAN NIC.  A quick reorder to give my External LAN priority and solved the DNS latency problem.  Now my host browses the internet as fast with and without my VM-DC booted.

BEFORE:

AFTER:

I'm not sure what set my Internal NIC with higher priority than my External NIC, but if it happens to you, this'll help!

The fix is pretty quick - just download the txt file, rename to PS1 and call it with the WebApp url.  It does little move than change the title of all alerts and changes it back.  This triggers the alert to be rewritten and handled correctly in 2010.

For my example, my 2007 DB was attached and upgraded to https://VM-SP2010A, so my call was:

.\AlertFix.ps1 https://VM-SP2010A

HTH

AlertFix.txt

Let's have a little background on why we have this. Here's a screenshot of the old values in the Responsibilities Field:

In previous 2007, I'd have to free text search for "SharePoint 2007" and again for "Migration" if I wanted to find this user.  If I wanted to search for both, our results could get skewed as users could have those terms in different order.  Is it possible?  Yes.  Is it easy?  No.  New with 2010 is the Managed Metadata service which eliminates this problem.  With the individual fields set to metadata, we enable the search refiners in SharePoint 2010 and the order is no longer an issue.  Is it simpler?  Absolutely.

While upgrading, there is a Powershell script to migrate the flat text field of the SSP 2007 to MMS in your new SharePoint 2010 environment called Move-SPProfileManagedMetadataProperty.  Unfortunately, if you are post June CU, there's a bug where you'll get this error message:

Move-SPProfileManagedMetadataProperty -ProfileServiceApplicationProxy <GUID> -Identity <Name of Field> -AvailableForTagging -TermSetName Responsibility
Move-SPProfileManagedMetadataProperty : UPDATE failed because the following SET options have incorrect settings: 'QUOTED_IDENTIFIER'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.
At line:1 char:38
+ Move-SPProfileManagedMetadataProperty <<<<  -ProfileServiceApplicationProxy 9
1740c45-b8c2-4ade-85bb-344f2a4eca47 -Identity SPS-Responsibility -AvailableForT
agging -TermSetName Responsibility
    + CategoryInfo          : InvalidData: (Microsoft.Offic...ProfileProperty:
   SPCmdletMigrate...ProfileProperty) [Move-SPProfileManagedMetadataProperty]
  , SqlException
    + FullyQualifiedErrorId : Microsoft.Office.Server.UserProfiles.PowerShell.
   SPCmdletMigrateDataForOneTaxonomicProfileProperty

If you BING search, you'll find that the Quoted Identifier is used to isolate quotes (") and apostrophes (') and this flag helps protect against SQL Injection attacks in SharePoint.  You'll also find (as stated here https://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/6fdb0ca3-5ac5-45ab-8663-af536e6dae24) that modifying the database works.  THIS PUTS YOU IN AN UNSUPPORTED STATE AND SHOULD NOT BE DONE WITHOUT MICROSOFT SUPPORT APPROVING THE CHANGE.

"Ok Ryan, so what's the fix?"  In short: we get around the Move-SPProfileManagedMetadataProperty bug by not using it!  Enter the User Profile Replication Engine (from the SharePoint Administration Toolkit: https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=20022).  The User Profile Replication Engine (or UPRE) has a -DoUpgrade switch which migrates the 2007 strings to 2010 MMS.  To make this work, you must have the old 2007 farm and new 2010 farm both online.  My old 2007 MySite Host is https://vm-moss:10378/ and my new 2010 MySite Host is https://vm-sp2010:13965/

Here's the walkthrough (Note: my SharePoint 2010 environment is called VM-SP2010.  My SharePoint 2007 environment is called VM-MOSS):

1) Install the SharePoint Administration Toolkit

2) Create an Managed Metadata Service (MMS) and User Profile Service (UPS) in the same proxy group (the same group is how the UPS knows which MMS to utilize)

3) Assign the proxy group to your 2010 MySite Host Web Application.  You can see here that my Web App is "SharePoint 2007MySites - 13965" and I have the MMS and UPS assisgned

4) Make yourself an administrator and full control to the MMS and UPS at _admin/ServiceApplications.aspx

 5) Start the UPRE and type in this Powershell command:

get-spprofilepropertycollection -source <2007 MySite Host URL> | start-spprofileservicefullreplication -source <2007 MySite Host URL> -destination <2010 MySite Host URL>  -MaxNumberOfThreads 3 -DoUpgrade

So, for my environment, I used:

get-spprofilepropertycollection -source https://vm-moss:10378/ | start-spprofileservicefullreplication -source https://vm-moss:10378/ -destination https://vm-sp2010:13965/  -MaxNumberOfThreads 3 -DoUpgrade

 And hit enter.  Wait for it to start enumerating profiles to insure you don't have any errors.  A full replication takes quite a while (1000 users on my environment took about 5 minutes).

6) Once complete, verify the multi-value property has been updated correctly by viewing a profile.  In this case, we'll use Administrator.

It works!

And there you have it.  If you have custom properties in 2007, you'll need to have the same custom properties in 2010.  The easiest way to do this is backup and restore your SSP database to 2010, then use it as the name of your Profile DB when you create your UPS.  That'll upgrade the DB to 2010 and bring your properties over.  From there,run a full import with UPRE following the steps above.

Problems with the UPRE need to be troubleshooted and then a recovery run.  Check out https://technet.microsoft.com/en-us/library/cc663011.aspx for steps to do that.

Hope this helps someone out there.  Any problems, let me know!