Office 2007/2010 format documents stored in SharePoint 2010 which have their title field populated show an incorrect title in the default search results. The screen shot below shows the search results for the following document:

Filename: Test document 1.docx
Title: Test Document 1 Title
First line of document: First line of test document 1

The title that is displayed as the link to the document at the top of the individual search result is the first line of text from the document, not the title (metadata) field. It should be noted that if the title field for the document is not set, the filename is displayed as the link to the document at the top of the individual search result, not the first line of text from the document.

Luckily, correcting this particular ‘feature’ is simple:

• Open registry editor
• Navigate to HKLM\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager
• Edit the ‘EnableOptimisticTitleOverride’ key and modify its value to 0:
  
• Restart the SharePoint Server Search 14 service by starting an admin command prompt and issuing the following commands:
  net stop osearch14
  net start osearch14
  
• Repeat the above steps for all SharePoint servers in the farm.
• Perform a full crawl on the SharePoint content source(s)

Once the full crawl has completed, performing the search again gives the title field as the search result title for a document which has the title field populated (note that in the screen shot below, test document 1 has the title field set, test document 2 doesn’t):

The following can be copied into a .reg file to automate setting the key, or the key could be set using PowerShell:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager]
"EnableOptimisticTitleOverride"=dword:00000000

I recently updated my Nokia Lumia 800 to the latest build, 1600.2483.8106.11500.

I’ve been keeping an eye on the battery capacity of my Lumia 800 following the reported battery charging issues using the phone diagnostics (which can be accessed by entering ##634# on the phone keypad, then from the list of applications afterwards) and noticed that following the update to the latest build, the reported full charge capacity started dropping. Initially it was around the 1350 mAh mark, following one full charge it dropped to about 1250 mAh, following the next it dropped to about 1140 mAh. Over the next couple of days it rallied a little, settling eventually at about 1180 mAh.

In reality I wasn’t too worried by the apparent drop in charge capacity, especially as the runtime following a charge was a good step up on what it had been before the update, but was concerned enough to drop Nokia a quick e-mail to ask them about the issue in case it was something they’d not come across before. My phone’s reported runtime was also lower than others in the office were reporting for theirs and I’ve seen some experiencing similar issues with their Lumia 800s on the Nokia forums.

Nokia’s support has been excellent. Following my initial e-mail to them, I had two very quick responses by e-mail asking for a few more details, followed by a call offering to collect the phone to run some diagnostics on it. Following a quick conversation with Robert however, it looks like I won’t need to take them up on their offer…

The solution in my case was to stop the tasks running in the background on my phone. After stopping the background tasks (go to settings, then slide one screen over to applications, then select background tasks and stop anything that is showing as running), RAC Traffic and one other in my case, I rechecked the battery diagnostics, and not only showed that the current being used had dropped by about half, but the reported battery full charge capacity had returned to it’s original state of over 1400 mAh.

Quite why a couple of running background tasks were influencing the reported full charge capacity of the battery, I’m not quite sure, but the method seems to be a reliable way to return the reported capacity of the battery to its full value.

Building a Hyper-V virtual machine from scratch almost always seems to involve mounting an ISO image at some point during the installation process. I suspect that like us, many other organisations already have a network location in which we store ISO images. The ability to mount an ISO image from our usual network location saves us having to copy the ISO images to the local Hyper-V servers.

The ability to remote mount an ISO image requires that a couple of configuration changes are made. Attempting to remote mount an ISO image without making the configuration changes usually results in an err along the lines of

Inserting the disk failed

Failed to add device ‘Microsoft Virtual CD/DVD Disk’

The file ‘\\RemoteServer\Share\ISO_Image.iso’ does not have the required security settings. Error: ‘General access denied error’

There are two configuration changes that need to be made. The first is ensuring that the Hyper-V hosts can access the share itself that contains the ISO images. As a workaround, you can always grant ‘Everyone’ read access to the share. If you want to control access to individual servers, you need to specify the Active Directory computer object for each server you want to give access to.

The second configuration change that is required to to grant Constrained Delegation on the virtual host objects in Active Directory:

• Log onto a domain controller and open Active Directory Users and Computers from the Administrative Tools menu, or open the remote administration Active Directory tools from another server or client
• Locate the Hyper-V host computer object
• Right-click the object and Select Properties from the context menu
• Select the Delegation tab
• Select the ‘Trust this computer for delegation to specified services only’ radio button and then the ‘Use any authentication protocol’ radio button
• Click the ‘Add’ button:
  
• The ‘Add Services’ dialog will open:
  
• Click the ‘Users or Computers’ button and add the remote server hosting the ISO images. Click OK
• Select the ‘cifs’ service type from the list shown:
  
• Click OK to close the dialog, the computer object properties should look like the following:
  
• Click OK to apply the change
• Repeat the above steps for any other Hyper-V hosts servers.

You should now be able to remote mount ISO images from the server specified.

Those of you who know me or Rik will know that we’re both very keen on Windows Home Server. I’ve seen some time related issues with my Home Server recently, with message in the event log telling me that the time of the system (which seems to drift more than I’d like) could not be updated due to a variety of issues.

Running a manual resync of the server time (open a command prompt and type w32tm /resync) gave the following error:

Sending resync command to local computer
The computer did not resync because the required time change was too big.

I was a little confused by this, as the drift was only a minute or so from what the other PCs in the house were showing. Checking the time synchronisation configuration on the server (open a command prompt and type w32tm /query /configuration) didn’t show any particular surprises except that the MaxNegPhaseCorrection and MaxPosPhaseCorrection were both set to 3600 (one hour) rather than the more normal 54000 (15 hours), however checking the time zone of the machine did; the server was configured to use PST! I could have sworn that I’d updated the time zone when I built the server, but obviously not…

Changing the time zone of the server sorted out the correct time, however running a synchronisation from the command prompt still gave an error:

Sending resync command to local computer
The computer did not resync because no time data was available.

There are a number of other switches that can be used with the w32tm command, one of which is /rediscover, which redetects the network configuration and rediscovers network sources. With the addition of this flag to the command (w32tm /resync /rediscover) gave me a successful time synchronisation:

Sending resync command to local computer
The command completed successfully.

My Home Server is now running on the correct time!

On the face of it, renaming the Managed Metadata Service Application database in SharePoint should be a fairly simple matter. There’s a test box for the database name in the properties of the Service Application and changing the name shown changes the database name. There are however one or two issues with changing the database name this way…

The image below shows a minimally configured Managed Metadata Service Application instance (some sample data has been added):

The database name can be easily changed by editing the properties of the Service Application and editing the name of the database:

The first of the issues experienced is that SharePoint now knows about two Managed Metadata Service Application databases. Checking the database list within the ‘review database status’ area of the ‘upgrade and migration’ section of Central Administration (a good place to get a complete list of the databases associated with a SharePoint 2010 farm) shows two Managed Metadata Service Application databases:

In addition, if the old database is deleted (using SQL Management Studio), the message ‘Not Responding’ will be shown against the database in the list (and errors will be shown in the event viewer of the machine hosting the Managed Metadata Service):

This is logical as SharePoint understands that there is a database associated with the farm that has been deleted.

The real problems have, however, only just started!

Looking at the Managed Metadata Service Application now shows the following:

In other words, although the database associated with the Service Application has been changed, the data contained within the original database has not been migrated. SharePoint has simply created a new Service Application database and associated that with the Service Application. If the database is renamed before any data has been added to the Service Application, this is not an issue, you’ll simply have to add administrators and data as you would normally. You’ll also have to remove the original database using the following PowerShell:

1. Get-SPDatabase
   Note the GUID of the original Managed Metadata Service Application database
2. $OldDB = Get-SPDatabase <GUID of the original database>
3. $OldDB.Delete()

To correct the issues shown above after renaming the database, assuming that the original database is still available, there are a couple of potential routes to take:

1. Perform steps similar to those outlined in the blog post ‘Renaming the PerformancePoint Service Application database in SharePoint 2010’ – I’d suggest the ‘backup and restore’ procedure from this blog post. Also note that the PowerShell command you’ll need to assign the newly renamed database to the Service Application is Set-SPMetadataServiceApplication <Identity> –DatabaseName <New DB Name>
2. Temporarily reattach the original database to the Service Application and export the data from it, before reattaching the new database and importing the data into it.

The PowerShell you’ll need to achieve the latter of the the above methods is:

1. Set the Service Application to use the original database:
   Set-SPMetadataServiceApplication "<friendly name of the Managed Metadata Service Application" -databasename <original DB name>
2. Issue an IISRESET on all servers in the farm
3. Export the Managed Metadata Service Application information:
   Export-SPMetadataWebServicePartitionData -identity <URL of the Web Application associated with the Service Application> -ServiceProxy “friendly name of the Service Application Proxy” -path <path and filename of the backup file to be used>.cab
4. Set the Service Application to use the new database:
   Set-SPMetadataServiceApplication "<Friendly name of the Managed Metadata Service Application" -databasename <new DB name>
5. Issue an IISRESET on all servers in the farm
6. Import the Managed Metadata Service Application information:
   Import-SPMetadataWebServicePartitionData -identity <URL of the Web Application associated with the Service Application> -serviceproxy "friendly name of the Service Application Proxy" -path <path and filename of the backup file to be used>.cab –OverwriteExisting

Note that using this method retains the original data in completeness, therefore all of the list associations with the Managed Metadata Service Application should continue to function without needing to be reconnected.

You can then delete the original database using the PowerShell commands detailed previously.

SharePoint can use multiple domains for user authentication, however I recently came across an issue when setting up an extranet using this scenario.

The steps for setting up SharePoint 2007 to use multiple domains for user authentication are relatively simple:

• Add the second domain as a user profile source in the SSP
• Issue the following stsadm command to encrypt the password for the account that is used to access the second forest or domain on each web front end server in the farm:
  stsadm –o setapppassword –password <password>
• Issue the following stsadm command to add multiple domains to the people picker search list:
  stsadm –o set property –pn peoplepicker-searchadforests –pv domain:<original resource domain>;domain:<secondary domain>,<domain>\<username>,<password> –url <web application URL>

At this point I could successfully add users from the second domain to the security groups in a site collection or site, however when I attempted to log in as one of these users, I received a “500 – Internal server error”. Logging in as a user from the original resource domain worked fine however.

Modifying the web.config file for the web application to set CallStack to true and CustomErrors to Off didn’t give me any further information, at least in Internet Explorer 8, as I still saw the same “500 – Internal server error”, however viewing the web application in Firefox gave me a somewhat cryptic error:

This error translates as STATUS_AUTHENTICATION_FIREWALL_FAILED, however the firewall wasn’t an issue in this scenario.

The solution was to grant the machine accounts for each of the web servers in the SharePoint farm an extra right in AD. The steps were:

• On a domain controller, start “Active Directory Users and Computers”
• On the view menu, ensure that the ‘Advanced Features’ option is checked
• Locate the computer account for first of the web servers in the SharePoint farm
• For the computer account, right-click and select properties and then click the security tab
• Add the <external domain>\Domain Users group to the security list and grant the ‘Allowed to authenticate’ right. Click OK to close the dialog.
• Repeat these steps for the computer accounts of all the other web servers in the farm

This resolved the issue and allowed users from the second domain to log into SharePoint.

Note that to achieve multiple domain authentication for SharePoint 2010, the same stsadm commands are used, and I therefore believe that the same issue may occur, however the above solution should also work for SharePoint 2010.

We’ve seen a couple of issues with a StarTech InfoSave 4-bay external hard drive enclosure (model SAT3540U2E) when trying to change the connection mode from USB to eSATA. Specifically, when following the instructions (which appear to state for example that when an eSATA connection is detected, the eSATA LED will light) to change the connection mode, pressing the interface button appeared to do absolutely nothing…

A quick live chat with one of StarTech’s support engineers provided the answer, which is to push and hold the interface button to change between USB and eSATA connections and vice-versa.

To summarise our findings so far:

• The default connection interface seems to be USB. Plugging the device into a computer using a USB cable allows the disks to be seen immediately.
• Plugging in the device using a eSATA cable does not result in the eSATA LED lighting.
• Pushing and holding the interface button for a couple of seconds allows the interface connection to be changed from USB to eSATA and back again.
• Plugging the device in using an eSATA cable without plugging in a USB cable does not automatically switch to using the eSATA interface.
• The sync button works in the same way as the interface button, i.e. push and hold for a couple of seconds to change the mode.

Modifying the URL used for CRM 2011 after installation can be achieved using the following steps:

• Update the IIS bindings for the CRM 2011 website on the server running CRM to the new value you want to use
• Open IIS Manager
• Select the Microsoft Dynamics CRM website
• Click ‘Bindings’ in the action panel at the right of the screen
• Select the binding to modify
• Click ‘Edit’ and modify the host name and port to the new value.
• Close the dialog and IIS Manager.
• Update the ServerURL registry entry with the new URL you want to use. The registry entry can be found at KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM. Note that the key value should be of the form http(s)://<New URL>:<Port Number>/MSCRMServices
• Modify the global settings for CRM from within the Microsoft Dynamics CRM Deployment Manager*:
• Start the Microsoft Dynamics CRM Deployment Manager
• Right-click on the ‘Microsoft Dynamics CRM’ entry at the top of the left pane of the window shown
• Click ‘Properties’
• Select the ‘Web Address’ tab on the dialog which is shown
• Modify the addresses shown appropriately. Note that if the binding type is modified from HTTP to HTTPS you will need to install the appropriate certificate into IIS as well.
• Click OK to close the dialog and close Microsoft Dynamics CRM Deployment Manager
• Restart the Microsoft Dynamics CRM Asynchronous Processing Service, or restart the server

* Note: This step replaces the use of the Microsoft CRM Deployment Configuration Tool used to make these changes for CRM 4.0.

While building a portion of our demo SharePoint 2010 farm, I encountered an error when publishing an Access 2010 database to a SharePoint 2010 Access Services site.

The error which was shown was ‘<URL> did not respond. Either the server does not exist, Microsoft Access Services are not enabled on the server, or the server is using an older version of Microsoft Access Services which is not compatible with Access 2010’:

After checking that the Access Services farm and web application features were enabled, and that the enterprise features were enabled on the site collection to which I was attempting to publish the Access database (all were fine), I looked in the server application logs on the WFE servers in the demo farm, and on one of the farm servers saw the error ‘There is no default Access Services Application Proxy’:

Checking the Service Application Associations (Central Administration –> Application Management –> Configure service application associations) showed that the Access Database Service proxy was not associated with the default proxy group:

After adding the Access Database Service proxy to the default group, publishing the Access database to SharePoint proceeded without a hitch.

In our case, the proxy not being associated with the default proxy group was due to us using PowerShell to configure the Access Service Application. If you do the same, check whether the proxy has been associated with the default group (or whatever proxy group you want it associated with).

During a recent SharePoint upgrade using the database attach method, I saw the following recorded in the upgrade error log:

[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: SPSite Url=http://intranet.domain.com
[powershell] [PerWebUpgradeAction (4.0.10.0)] [WARNING] [13/04/2011 15:55:48]: Minimal master page failed to provision: could not find master page gallery.
[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: SPSite Url=http://intranet.domain.com
[powershell] [PerWebUpgradeAction (4.0.10.0)] [WARNING] [13/04/2011 15:55:48]: V4 master page failed to provision: could not find master page gallery.
[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: SPSite Url=http://intranet.domain.com

Further information was provided in the upgrade log that accompanies the error log:

[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: Setting UIVersion metadata on existing default master page
[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: Provisioning minimal master page in site: Site1
Site Url: http://intranet.domain.com/Site1
[Powershell] [PerWebUpgradeAction (4.0.10.0)] [WARNING] [13/04/2011 15:55:48]: Minimal master page failed to provision: could not find master page gallery.
[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: Provisioning V4 master page in site: Site1
Site Url: http://intranet.domain.com/Site1
[powershell] [PerWebUpgradeAction (4.0.10.0)] [WARNING] [13/04/2011 15:55:48]: V4 master page failed to provision: could not find master page gallery.
[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: Setting UIVersion metadata on existing default master page
[powershell] [PerWebUpgradeAction (4.0.10.0)] [WARNING] [13/04/2011 15:55:48]: Could not find master page gallery. Metadata on default.master not set.

The farm in question was originally a SharePoint 2003 farm that had been in-place upgraded to SharePoint 2007. The site recorded in the upgrade error log had been created in SharePoint 2003, but had not had its template selected at the time of original creation, allowing the first site user to pick the template to use. Critically however, this had never been done.

Once the database upgrade had been completed, navigating to the site gave me the expected screen to allow me to select the site template to use. Picking a template and clicking OK however produced a ‘file not found’ error.

The moral of the story seems to be ensure that any sites created without selecting a site template should either be completed, or deleted before the upgrade process starts. Note that you can still delete a site that has been upgraded to 2010 in the above state using PowerShell. Detection of sites such as these in SharePoint 2007 is straightforward using stsadm –o enumallwebs – any site that doesn’t have a template shown against it is in this state.