Andy Dawson's Blog

Posts on this blog are usually IT related so I thought it might make a change to write about something that, while still technology related, is a little different…

As some of my colleagues will attest to, I firmly believe in a well insulated house and buying products for the home that are as efficient as possible. My Home Server, for example, runs on a low power CPU in an effort to reduce the day-to-day running costs.

Many of our lights at home have already been converted to use CFL bulbs, replacing the original incandescent bulbs. I’m not a great fan of CFL bulbs however for a couple of reasons:

• The start-up time of some bulbs still seems to be long (not that that is necessarily an issue on a winter morning when I don’t want to be immediately blinded when switching the lights on)
• The bulbs contain mercury (albeit in small amounts); if you break a bulb, both the bulb and the items you use to clean up should be treated as hazardous waste (see http://archive.defra.gov.uk/environment/business/products/roadmaps/lightbulbs.htm for details)

On the plus side however, exchanging the incandescent bulbs for CFL ones has significantly reduced the number of bulbs I have to change. Our living room light, for example, used to need a bulb changing on average once per month as opposed to about once every 2-3 years for CFL bulbs. In addition, my (albeit approximate) calculations suggest that we save about £5-7 per bulb per year in energy costs, so in general the CFL bulbs pay for themselves within a few months.

Many of our new lights however use GU10 incandescent bulbs and while GU10 CFL bulbs are available, they are typically longer than the original incandescent bulbs and so will not fit in many of the housings (e.g. in spotlights etc.)

LED bulbs are however available and with recent improvements to LED technology, can now match the light output of the incandescent bulbs they replace. Even better, many of the GU10 LED replacements are exactly the same size as the original bulbs and are therefore direct replacements. I like LED bulbs for the following reasons:

• Fast start – LED lights are at full output almost immediately. In fact they beat an incandescent bulb, one of the reasons that they are used in brake lights on many cars these days
• ‘Warm white’ bulbs are now available. White LEDs always used to be ‘cold white’, i.e. showed a significant blue cast, making them a very harsh light. Great for some specific applications, but not so nice for everyday use. Dimmable bulbs are also available.

The bulbs I favour are as follows:

These have 20 SMD LEDs and produce a light output equivalent to a 50W incandescent. Hopefully if there are failures of the individual LEDs within the bulb, the failure will be gradual rather than suddenly stopping working completely, giving us time to source replacements.

I have, however, found an issue when replacing a set of incandescent GU10 bulbs with their LED equivalents. We replaced a set of 4 bulbs in a kitchen fitting with LED bulbs and found that when the lights were switched off, the bulbs still glowed gently. With a single incandescent bulb and 3 LED bulbs in the fitting, the issue didn’t occur. Following a little research, it became obvious that even with a properly earthed system, the capacitively coupled power from live to switched live is enough to cause an LED bulb to glow gently. With an incandescent bulb in the fitting, the resistance of this bulb was low enough to effectively absorb the leakage current and stop the LEDs from glowing.

There is a solution to the issue, which is to fit a resister-capacitor combination (a contact suppressant; not designed for this purpose, but works perfectly well) across the terminals of the light fitting. These can either be a DIY solution, but I have found a product recommended for this purpose, which is a combination 0.1uF capacitor and a 100 ohm resistor in a package suitable for use with 240V AC:

The link goes to a Farnell page, but I am sure that there are also available from other quality electronics resellers. There is also a 0.22uF version for longer circuits, should that be required. I’d strongly recommend using a bit of heat-shrink tubing on each lead of the package to ensure that the supply will not come in contact with the light casing.

Adding one of these devices to our kitchen light has completely solved the issue of the bulbs glowing even when switched off. The LED bulbs are saving something like 90% of the energy (and therefore the running costs) that would be consumed by incandescent bulbs and hopefully they will have a very long life span.

Rik, Andrew and I will be at some of the upcoming UK TechDays that are being held.

I can’t recommend these days highly enough and every attendee that I have spoken to at previous events has found them both thoroughly enjoyable and useful.

Rik, Andrew and I will be at the System Center 2012 SP1 IT Pro camp tomorrow (19th February) – we hope to see you there!

Further information on the IT camps can be found at:

If you want to know more about forthcoming TechDays keep an eye on the main events page.

My last post about the SharePoint 2013 MySite Newsfeed and required additional permissions on the User Profile Service Application dealt with adding the required permissions to the UPSA using the SharePoint 2013 GUI. Alternatively, you can add the required permissions using PowerShell:

#Grab a reference to the User Profile Service Application
$serviceapp = Get-SPServiceApplication | where {$_.DisplayName -eq "User Profile Service Application"}

#Return the SPObjectSecurity object for the Service Application
$security = Get-SPServiceApplication $serviceapp | Get-SPServiceApplicationSecurity

#Setup our claim provider
$claimprovider = (Get-SPClaimProvider System).ClaimProvider

#Specify the required principal
$principal = New-SPClaimsPrincipal "Domain\UPSAppAccount" -IdentityType WindowsSamAccountName

#Grant the required permissions on the Service Application
Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Control"
Set-SPServiceApplicationSecurity $serviceapp -ObjectSecurity $security

Using PowerShell allows us to add this part of the configuration to a script rather than having a manual step to perform once the PowerShell has completed (as we all know, these additional manual steps tend to get forgotten).

This is an issue that we've been bumping up against and have seen a number of other users seeing the same problem with SharePoint 2013 implementations.

When looking at the 'Everyone' tab on a user's MySite, the following message is displayed:

and the following entries appear in the SharePoint logs:

Failure retrieving application ID for User Profile Application Proxy 'User Profile Service Proxy': Microsoft.Office.Server.UserProfiles.UserProfileApplicationNotAvailableException: UserProfileApplicationNotAvailableException_Logging :: UserProfileApplicationProxy.ApplicationProperties ProfilePropertyCache does not have c2d5c86f-e928-4abf-b353-a8ab7809766c     at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_ApplicationProperties()     at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_AppID()           0e49dc9b-d278-1089-b021-6e2138766eae

SPMicrofeedFeedCacheService.GetUserProfile() - UserProfileApplicationProxy not available     0e49dc9b-d278-1089-b021-6e2138766eae

To correct this issue, complete the following steps:

1. Log onto the SharePoint 2013 Central Administration site as a farm administrator
2. Navigate to 'Manage Service Applications'
3. Highlight the User Profile Service Application
4. Click the 'Permissions' ribbon toolbar button:
   
5. Add the account that is used to run the User Profile Service Application and give it full control:
   
6. Click OK

At this point it is usual to see the following displayed in the 'Everyone' tab of the user's MySite:

It's worth checking the SharePoint logs at this point to see what additional errors may be reported (note that you will see 'We're still collecting the latest news' if no users have posted anything, so create a post to ensure that you have something waiting in the queue). In my case, I saw the following:

System.Data.SqlClient.SqlException (0x80131904): Cannot open database "SP_Content_MySite" requested by the login. The login failed.  Login failed for user 'Domain\UPSApp'.

This can be solved by completing the following steps:

1. Open the SharePoint 2013 Management Shell by right-clicking and choosing 'run as administrator'
2. Issue the following PowerShell commands
   $wa = Get-SPWebApplication http://<MySiteURL>
   $wa.GrantAccessToProcessIdentity("domain\UPSApp")

At this point, the newsfeed should be up and running successfully:

I recently saw a CRM 2011 instance which had had and issue with SQL Reporting Services. To correct the issues with the Reporting Services server, which was separate to the CRM 2011 server, SQL Reporting Services has been completely reinstalled on the server. Following this action, there were a few steps that needed taking to get reports working again in CRM.

• The CRM reporting services extensions needed to be reinstalled and patched on the Reporting Services server.
• The CRM reports needed republishing to the Reporting Services server. This was achieved by running the following command:
  PublishReports.exe <CRMOrganisationName>
  Note: The PublishReports.exe tool can be found in C:\Program Files\Microsoft Dynamics CRM\Tools folder on the CRM server.
  Note: The <CRM OrganisationName> is displayed under 'Organizations' in the Microsoft Dynamics CRM Deployment Manager.

Once both these steps were taken, some of the reports still didn't work, especially reports that had been generated using CRM's report wizard. The error reported on the report display page was:

Report render failure. Error: An error has occurred during report processing. (rsProcessingAborted)

Kerberos had been setup correctly for the CRM server and had been checked (see KB2590774 but note that the account for which SPNs are set should also be trusted for delegation).

Examination of the CRM logs showed the following errors:

System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://CRMServer/CrmSandboxSdkListener-w3wp. The connection attempt lasted for a time span of 00:00:21.0185095. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond XXX.XXX.XXX.XXX:808.

System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond XXX.XXX.XXX.XXX:808 ---> Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: An unexpected error occurred. ---> Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: Could not connect to net.tcp://CRMServer/CrmSandboxSdkListener-w3wp. The connection attempt lasted for a time span of 00:00:21.0185095. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond XXX.XXX.XXX.XXX:808.  ---> Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond XXX.XXX.XXX.XXX:808

By default, a firewall rule named 'Windows Communication Foundation Net.TCP Listener Adapter (TCP-In)' on port 808 is available on Windows, but is not activated by the CRM installation. For fetch-based reports to work correctly when Reporting Services in installed on a different server to CRM, this firewall rule needs to be enabled on the CRM server.

I've installed VAMT 3.0 to work with Windows 8 and came across an issue where it crashed on launch:

Despite there being no mention of it on the VAMT 3.0 requirements page, it actually requires .NET 3.5.

Once installation of .NET 3.5 was complete, VAMT 3.0 started correctly.

During a recent WSUS upgrade from an old server to a new virtual machine running Windows Server 2008 R2, I saw an issue with the server not downloading updates correctly. The server appeared to synchronise correctly, but then no updates were downloaded.

We originally saw an issue like this when we started using Microsoft Threat Management Gateway, and the errors reported in the application event log on the new WSUS server were the same, namely:

Error 10032: The server is failing to download some updates

Error 364: Content file download failed. Reason: The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header.

Microsoft KB article 922330 provides a solution for this specific issue, in our case we're using a pre-existing SQL Server, so went with

"%programfiles%\Update Services\Setup\ExecuteSQL.exe" -S %Computername% -d "SUSDB" -Q "update tbConfigurationC set BitsDownloadPriorityForeground=1"

However this didn't solve the issue.

In our case, the existing instance of SQL was on another server, so the command should have been:

"%programfiles%\Update Services\Setup\ExecuteSQL.exe" -S SQLServerName\Instance -d "SUSDB" -Q "update tbConfigurationC set BitsDownloadPriorityForeground=1"

Once the revised command had been run and the WSUS server restarted, the update downloads started automatically.

On an instance of CRM 2011 that was being patched to Update Rollup 6 prior to patching to Update Rollup 8, the following error occurred:

System.Exception: Action Microsoft.Crm.Setup.Common.Update.DBUpdateAction failed. ---> System.Data.SqlClient.SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

The error was displayed as both a dialog on screen, and within the log file, KB2600640.log located at %APPDATA%\Microsoft\MSCRM\Logs

The solution was to raise the timeout that CRM applied for OLEDB connections from the original 30 seconds by creating two new registry keys at HKLM\SOFTWARE\Microsoft\MSCRM:

OLEDBTimeout (DWORD), value 86400 (decimal)
ExtendedTimeout (DWORD), value 1000000 (decimal)

Then restart the CRM application pool within IIS.

Once the new settings were in place, the upgrade proceeded normally.

Extending some of the default content types available in SharePoint 2010 can result in unwanted fields being shown. An example is extending the 'Event' default content type, which has three fields attached which you don't seem to be able to edit:

In particular, many users would like to remove the Workspace field from calendar entries:

Some users resort to editing the new/edit/view forms to remove the fields that are not wanted, however there is an easier way!

Using the following PowerShell, an unwanted field can be hidden so that it does not appear in the new/edit/view forms:

 1 # Get a reference to the web we are using
 2 $web = Get-SPWeb https://intranet.domain.com/site
 3 
 4 # Get a reference to the list to which the content type is attached
 5 $list = $web.Lists["Holiday Calendar"]
 6 
 7 # Return a list of the fields
 8 $fields = $list.fields
 9 
10 # Select the field we wish to hide
11 $field = $fields | where {$_.internalname -eq "WorkspaceLink"}
12 
13 # Show the current 'hidden' status of the field
14 $field.Hidden
15 
16 # Set the field to hidden (note that 'CanToggleHidden' must be true to allow this)
17 $field.Hidden = $true
18 
19 # Update the field
20 $field.Update()

Creating a new holiday event on the calendar, the field allowing a user to create a workspace is now hidden:

The default communication scheme for many of the SharePoint 2010 Service Applications is ‘http’ (i.e. unsecured). This can be changed easily in the GUI by selecting the service application and clicking the ‘publish’ ribbon button:

It should however be noted that a number of Service Application communication schemes run by default over https and cannot be modified, these are:

• Application Discovery and Load Balancer Service Application
• Search Administration Web Service
• Secure Store Service Application
• Security Token Service Application

The communication scheme of a few Service Applications cannot be inspected using the GUI (and the publish ribbon button remains greyed out when they are selected):

• SharePoint Server ASP.NET Session State Service
• SharePoint Session State Service Application
• WSS_UsageApplication

Modifying the communication scheme of all of the Service Applications can be time consuming and can be error prone, especially when using SharePoint 2010 Enterprise and the Office Web Applications with all of the Service Applications available configured for use. With this in mind, the following PowerShell will change the communication scheme of all of the Service Applications where it is possible to do so to https:

 1 # This script sets the communication scheme of all Service Applications to be https instead of http
 2 # Note that the communication scheme for a number of Service Applications cannot be changed
 3 
 4 # Grab a list of the Farm's Service Applications
 5 $ServiceApps = Get-SpServiceApplication | Sort-Object TypeName
 6 
 7 # Iterate through the Service Applications
 8 foreach ($ServiceApp in $ServiceApps)
 9 {
10     if (($ServiceApp.TypeName -ne "Application Discovery and Load Balancer Service Application") `
11       -and ($ServiceApp.TypeName -ne "Search Administration Web Service Application") `
12       -and ($ServiceApp.TypeName -ne "Security Token Service Application") `
13       -and ($ServiceApp.TypeName -ne "Secure Store Service Application") `
14       -and ($ServiceApp.TypeName -ne "SharePoint Server ASP.NET Session State Service") `
15       -and ($ServiceApp.TypeName -ne "State Service") `
16       -and ($ServiceApp.TypeName -ne "Usage and Health Data Collection Service Application"))
17     {
18         # We can modify the communication scheme
19         Write-Host "Current communication shceme for" $ServiceApp.DisplayName ":" $ServiceApp.DefaultEndpoint.Name
20         if (($ServiceApp.DefaultEndpoint.Name -eq "https") -or ($ServiceApp.DefaultEndpoint.Name -eq "secure"))
21         {
22             Write-Host "Service Application already using https, skipping" -ForegroundColor Red
23         } else {
24             # Change the communication scheme to https
25 
26 
27             if ($ServiceApp.TypeName -eq "PowerPoint Service Application") {
28                 # PowerPoint Service Application has "fast" instead of "http" and "secure" instead of "https"
29                 $SAEhttps = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "secure"}
30             } else {
31                 $SAEhttps = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "https"}
32             }
33             Write-Host "Setting Service Application communication scheme to https" -ForegroundColor Green
34             $ServiceApp.DefaultEndpoint = $SAEhttps
35             $ServiceApp.Update()
36         }
37         Write-Host "`n"
38     } 
39 }

To reverse these changes, and set the communication scheme of all Service Applications for which it is possible to modify the communication scheme, the following PowerShell can be used:

 1 # This script sets the communication scheme of all Service Applications to be http instead of https
 2 # Note that the communication scheme for a number of Service Applications cannot be changed
 3 
 4 # Grab a list of the Farm's Service Applications
 5 $ServiceApps = Get-SpServiceApplication | Sort-Object TypeName
 6 
 7 # Iterate through the Service Applications
 8 foreach ($ServiceApp in $ServiceApps)
 9 {
10     if (($ServiceApp.TypeName -ne "Application Discovery and Load Balancer Service Application") `
11       -and ($ServiceApp.TypeName -ne "Search Administration Web Service Application") `
12       -and ($ServiceApp.TypeName -ne "Security Token Service Application") `
13       -and ($ServiceApp.TypeName -ne "Secure Store Service Application") `
14       -and ($ServiceApp.TypeName -ne "SharePoint Server ASP.NET Session State Service") `
15       -and ($ServiceApp.TypeName -ne "State Service") `
16       -and ($ServiceApp.TypeName -ne "Usage and Health Data Collection Service Application"))
17     {
18         # We can modify the communication scheme
19         Write-Host "Current communication shceme for" $ServiceApp.DisplayName ":" $ServiceApp.DefaultEndpoint.Name
20         if (($ServiceApp.DefaultEndpoint.Name -eq "http") -or ($ServiceApp.DefaultEndpoint.Name -eq "") -or ($ServiceApp.DefaultEndpoint.Name -eq "fast"))
21         {
22             Write-Host "Service Application already using http, skipping" -ForegroundColor Red
23         } else {
24             # Change the communication scheme to https
25             if ($ServiceApp.TypeName -eq "Visio Graphics Service Application")
26             {
27                 # Visio Graphics Service Application has "" instead of "http" (equivalent to "default" in the GUI)
28                 $SAEhttp = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq ""}
29             } elseif ($ServiceApp.TypeName -eq "PowerPoint Service Application") {
30                 # PowerPoint Service Application has "fast" instead of "http" and "secure" instead of "https"
31                 $SAEhttp = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "fast"}
32             } else {
33                 $SAEhttp = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "http"}
34             }
35             Write-Host "Setting Service Application communication scheme to http" -ForegroundColor Green
36             $ServiceApp.DefaultEndpoint = $SAEhttp
37             $ServiceApp.Update()
38         }
39         Write-Host "`n"
40     } 
41 }

Note that an IISRESET will be required on all servers in the farm once either of the above PowerShell scripts has been run to complete the modification of the communication scheme.