Fortunately, I colleague of mine, Denis Heliszkowski, had a cunning solution. Starting on your source environment, follow these steps:

1. Copy (Ctrl-C) the file from the Explorer window
2. Open WordPad and paste the document in there, it will then look something like this:
   
3. Now, copy this file again, but now from WordPad.
4. Switching to your target environment (typically your own PC)
5. Open WordPad and paste into the empty document
6. Again, copy this file from WordPad
7. Open Explorer and paste

Voila – your file has been transferred to your local disk!

This of course also works in the other direction, which can be useful if you need to copy something like the Sysinternal tools to a server which does not have connectivity to the internet.

I must admit that I cannot in detail explain why or how this works. According to Denis, it’s about the file object being converted to a COM object when inserted into a document. I gues the most important thing is that it just works.

When the user has entered his credentials, a cookie is returned to the client (when using claims authentication or other cookie-based authentication methods). This cookie is contained in the header of the requests as long as the user is logged in.

Internet Explorer stores up to 50 cookies per domain. This means that if your code generates a lot of cookies, your authentication cookie might sooner or later be lost (as cookies are handled on a First-In-First-Out basis).

SharePoint list view pages generates cookies (normally 2). After browsing a number of list view pages the browser will receive a high number of cookies. When the number reaches 50, the authentication cookie will be replaced in IE. What the user will experience is that he is "thrown out" (redirected to the log-in page).

If we log on through firefox we can easily see all the cookies generated through firebug

This picture shows the "View all site content page". There are currently 6 cookies from the site domain. After browsing all the list view pages linked from this page we get the following cookies:

As you might see at the picture, the cookies stsSyncIconPath, stsSyncAppName, databaseBtnText and databaseBtnDesc (depending on list type) cookies are written to list relative paths. After browsing a number of pages like these, the number of cookies will sooner or later reach 50. If the user is browsing through IE, the authentication cookie (FedAuth in this example) will be lost.
Note: if you debug the same behavior through Fiddler you will not be able to see these cookies as they are generated client side (through javascripts).

If you do experience this issue you could consider a couple of workarounds:

- Wait for a future fix (the behavior will hopefully be changed in one of the next SharePoint CUs)

- Avoid exposure of list views unless you really need them

- Take a look at how the cookies are generated (hint: ows.js/init.js). Remember that modifying the out of the box files is not supported by Microsoft

• Manual editing of XML files only works for really small files
• Deployment is cumbersome - it must be done on each server, and the path includes GUIDs

We therefore decided to script the rollout, taking a CSV file as input. CSV is easily edited using Excel, and PowerShell is great at parsing CSV and writing XML. This way, both problems could be easily solved. But, as we started trying this out, we ran into additional challenges:

• Adding anything except letters, numbers and spaces seem to breaks the feature
• In some environments, the reference to the XML schema causes problems
• Duplicate synonym entries makes the feature fail silently (this caused us a lot of headache…)
• We needed to log onto each individual search server to restart it

The XML schema problem appears in the event viewer and looks like this:

We found that removing the XML namespace reference at the start of the XML file solved the problem.

To make a long story short, we have created a script which handles everything you need:

• Converts CSV to XML
• Replaces, &, :, ;, etc. with spaces
• Barfs at you if you have duplicates
• Looks up the correct guid-folders for your servers
• Distributes the XML files
• Does an automatic restart of the OSearch14 windows service on all servers listed

Configuration is done via a simple PowerShell file which is passed as input to the main script. A couple of things to note regarding configuration:

• An arbitrary number of columns can be added - just make sure to add corresponding dummy-headings. Headings are required for PowerShell to parse the CSV properly.
• Deploying to "tsneu" is probably sufficient, as is done in the supplied config, but you can add a list of languages if needed.

Download the attached zip for the complete source. Thanks to my colleague Stig Lytjohan for doing much of the hard work!

Enjoy!

ConfigureSearchSynonyms.zip

When hovering over the persons name, you should get the option to view the persons profile page, or “My Site”. But in a standard installation, this connection is not enabled, and you will only be able to highlight the name, e.g. as shown here:

In an installation with a proper MySite-link, it will look like this when I hover over “Thomas Svensen” in the popup:

And clicking the name will open the person’s MySite in your default browser. Worth noting here is that there is not a direct link to the user’s MySite, instead the My Site that you are connected to, is queried using the email address of the person in question. This can be verified by using Fiddler to show the trace of network calls made.

This link to the user’s MySite is stored in the Registry:

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Server Links\Published\My Site\Profile Site]
"LinkType"=hex(b):00,00,00,00,00,00,00,01
"IsMember"=dword:00000000
"IsPublished"=dword:00000001
"Url"="https://my:80/Person.aspx?user="

I have highlighted “My Site” in the registry path, because this name can be anything. Testing has shown that the first entry listed under “Published” is used, whatever the name is. With SharePoint 2010, the only way we have found to create this link in the registry, is to:

1. Open some document library
2. Click “Library tools > Library” in the ribbon
3. Click “Connect to Office > Add to SharePoint sites”
4. Click “OK” in the dialog that appears.

This procedure is not really something we can instruct all our thousands of users to do, of course. There are some suggestions floating around on the net, saying that the PortalConnect popup that appeared in earlier SharePoint version can be enabled for SP2010, e.g. as described by Stef van Hooijdonk. But applying those registry updates didn’t not change anything for us; neither does it seem to work for others on the SharePoint TechNet forum. The obvious alternative is pushing out the registry update shown above via a GPO – Group Policy Object, but there is no official guidance on this, e.g. in the Office 2010 Group Policy and OCT Settings reference spreadsheet. We are trying to get some guidance, but currently, this is the state of affairs.

$webapp = Get-SPWebApplication https://<your web app url>
$w.WebConfigModifications

If you want to remove an invalid entry, use the following commands:

$modification = $webapp.WebConfigModifications | where { $_.Name -eq "<the name of your key>" }
$webapp.WebConfigModifications.Remove($modification)
$webapp.Update()

[HKEY_USERS\<userid>\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
"State"=dword:00023e00

1. The log disk is full.
2. The application pool account of your web application is not a member of the  "Performance Log Users" group on ALL servers in the farms.
3. For being able to create custom event logs from an event receiver, the timer service account needs write permissions to the following key in registry:
   
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicese\Eventlog

If you are just starting to implement logging in your application, a few tips may help you on the way:

• A good logging experience requires some effort, so you may find that using the logging classes in Patterns & Practices SharePoint Guidance can save you some work.
• ULS Viewer is of great help when reading the ULS log. Download it from MSDN: https://archive.msdn.microsoft.com/ULSViewer

• long-old-url.company.com –> 10.10.10.10
• nice-url.company.com –> 10.10.10.10

This way, both new and old users could access the same backend transparently. But, we wanted the old users to be redirected to the new URL, so that going forward everyone would see “https://nice-url.company.com” in their browser address bar. Fortunately, version 7 of IIS added support for redirects. But it turns out that the redirect module is not enabled by default. You must go into the “Windows features” to enable it.

Once the redirect feature was enabled, it was easy enough to configure the redirect using the UI.

UPDATE:
I though it was this easy, but it turns out that query parameters are not passed along when using the straightforward redirect function, but you need to add $V$Q and check the "Exact destination", like this:

As we have multiple environments were this needs to be configured, we wanted to do it all via the command line. It took some research to figure out the steps to activate the windows feature and even more to do the IIS configuration via the command line. So, for your convenience, here is a complete batch script which takes as input four parameters and sets it all up in one go. The four parameters are:

1. Old URL
2. New URL
3. Old port (defaults to 80)
4. New port (defaults to 80)

And here is the complete script with inline comments to explain the required steps:

@echo off

REM Configuration
set oldUrl=%1
set newUrl=%2
if "%3" == "" (set oldPort=80) else (set oldPort=%3)
if "%4" == "" (set newPort=80) else (set newPort=%4)

set siteId=1001
set siteName=%oldUrl%
set virtualDir=c:\inetpub\wwwroot\wss\VirtualDirectories\%oldUrl%-%oldPort%

REM ************************************************
REM Enable HTTP Redirect feature
REM ************************************************
dism /online /Enable-Feature /FeatureName:IIS-HttpRedirect

REM ************************************************
REM Create virtual directory for site
REM ************************************************
mkdir "%virtualDir%"

REM ************************************************
REM Create site
REM ************************************************
%windir%\system32\inetsrv\AppCmd ADD SITE /name:%siteName% /id:%siteId% /bindings:http/*:%oldPort%:%oldUrl% /physicalPath:"%virtualDir%"

REM ************************************************
REM Add redirect setting to web.config
REM ************************************************
%windir%\system32\inetsrv\AppCmd SET config %siteName% /section:httpRedirect /enabled:true /destination:https://%newUrl%:%newPort%$V$Q /exactDestination:true

REM ************************************************
REM Grant read access to Everyone recursively
REM (Automatic when done via UI, but not via cmd)
REM ************************************************
icacls "%virtualDir%" /t /q /grant:r everyone:(GR)

ConfigureIISRedirect.cmd.txt

New-SPSubscriptionSettingsServiceApplicationProxy
New-SPBusinessDataCatalogServiceApplicationProxy
New-SPMetadataServiceApplicationProxy
New-SPSecureStoreServiceApplicationProxy
New-SPStateServiceApplicationProxy
New-SPEnterpriseSearchServiceApplicationProxy
New-SPPerformancePointServiceApplicationProxy
New-SPProfileServiceApplicationProxy
New-SPVisioServiceApplicationProxy
New-SPWebAnalyticsServiceApplicationProxy

For custom service applications it’s a little bit more complicated. By the way, I most cases you need to set up a trust relationship between the servers before trying to connect the proxy. This also applies to the out-of-the box proxies. The next step is to get the connection URI for the service application. You can use the topology web service for that:

$connectionUri = (Receive-SPServiceApplicationConnectionInfo `
    -FarmUrl https://publisher:32844/Topology/topology.svc

Next, loop through all the service proxies to find the right proxy type. Notice that we need to look at each service proxy through the eyes of the IServiceProxyAdministration interface to get access to the GetProxyTypes method.

foreach($sp in (Get-SPFarm).ServiceProxies)
{
    $spa = $sp -as `
      [Microsoft.SharePoint.Administration.IServiceProxyAdministration]
    $types = $spa.GetProxyTypes()
    $type = $types | ? { $_.FullName –eq $ProxyTypeName }
    if ($type –ne $null) { break }
}

Finally, create and provision the proxy:

[Microsoft.SharePoint.Administration.SPServiceProvisioningContext] `
    $provisioningContext = $null
$serviceApplicationProxy = $serviceProxyAdministration.CreateProxy( `
    $type, "NG Proxy", $connectionUri, $provisioningContext)
$serviceApplicationProxy.Provision()

(Using null for the provisioning context parameter seems to work fine, so I didn’t spend more time trying to figure out what that value should be.)

You can now verify that the service proxy is available in Central Administration | Manage service applications.

NOTICE! To make this post more readable all error handling has been removed from the scripts.