Thursday 8 March 2012

Setting up User Profiles Reminder

Problem:  Over the last few years I have to re-setup user profiles fairly often and each time I try do it from memory and it fails.  Once again tonight I messed it up on the 1st run.

Resolution:
This Technet article on UPS is key follow the steps: http://technet.microsoft.com/en-us/library/ee721049.aspx
Good simple video on setting up the AD connection and synchronising the UPS http://www.microsoft.com/resources/technet/en-us/office/media/video/video.html?cid=stc&from=mscomSTC&VideoID=04fc6247-66ae-4902-9e5e-7c6fd030ef0f

More Info:

PowerShell to determine NetBios/Hostname and FQDN on the local machine:
PS> $obj_IPProperties = [System.Net.NetworkInformation.IPGlobalProperties]::GetIPGlobalProperties()
PS> "FQDN: {0}.{1}" -f $obj_IPProperties.HostName, $objIPProperties.DomainName
PS> $obj_Computer = Get-WmiObject -Class Win32_ComputerSystem
PS> "NetBios: {0}" -f $obj_Computer.Name

J Curves with SharePoint implementations

When speaking to a client or prospecive customer, everyone wants to hear how SharePoint will solve all you problems and IT will live in Utopia for the next 10 years.  Obviously there is a lot of work and planning to get improved performance never mind an ideal scenario.

In the past I try tell the client how it will get worse before it get's better (the dreaded J-curve).  Robert Bogue has put this down nicely.  Post the sales patter definitely worth addressing as early as possible.

Sunday 4 March 2012

Office document in SP2010 won't open - Explorer fails, SDP fails.

Problem: Can't open Office documents (Word, Excel or PowerPoint).  Additionally can't connect to SharePoint using SPD2010 or Publish forms using InfoPath 2010.  Another effect has been that Windows Explorer won't display document library's.
Initial Hypothesis:  A colleague of mine Grzegorz Skorupa in Poznan figured out the issue using Fiddler.  Our site was running over SSL so he had to decrypt the response's and requests using Fiddler.  Fiddler was also used to intercept the requests from the Office client program.  From this he could see MS Word issuing more than simply GET and POST verbs.  Recently our SharePoint test environment had been hardened which include only allowing GET & POST verbs.  This also only occurs if you are using STSsession cookies.  This was previously discussed http://blog.sharepointsite.co.uk/2010/11/change-to-session-cookies-for-claims.html

You can check your farms cookies session setting using the following PowerShell cmd:
PS> Get-SPSecurityTokenServiceConfig

As it has been explained to me, because the session cookies are being used, the cookies are no longer written to disk, so the Office application needs to authenticate (as it can't use the cookie created by the SharePoint browser session). The Office client uses WebDAV request, has to authenticate and it passes requests that are not GET or POST based to retrieve the file.

Resolution:  Check IIS and the instances of IIS are allowing all verbs in request filtering or use the default sessioncookies setting (false).
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $false
$sts.Update()
iisreset

You can watch the http request types (request verbs) using Fiddler as highlighted below.

SPO 2nd update Statement

SPO made it's 1st update statement in October 2011 which allows BCS (web services) on SharePoint Online.  This is the 2nd change to the SP2010 online version (Feb 2012),
Ability to scale up to 500K users was 20k.
Site Collection Recycle Bin - ability to self restore includes a full site collection restore.
Ability to invite non-domain users  - Simplifies Collaboration with partners, customers, etc as they can use their own email adrs.
Changes to how your browser handles to PDF files - use to have to download and then open the pdf document.  Now will open pdf reader once clicked.

Saturday 25 February 2012

SharePoint CoE & Estimating SharePoint Projects

Overview:  On Tuesday 21st of February I present a real world experience of a method of estimating and providing a high level design for SharePoint projects as done in our CoE at the SharePoint User Group UK (SUGUK) meeting in Nottingham.

Here is the slide deck (pptx) 1.1MB

Also see:
http://blog.sharepointsite.co.uk/2011/11/sharepoint-center-or-excellence.html


Quick Way to Verify your Build

Problem: Going to a new client you need to work out each of their enviroments, this can be done using CA, PowerShell and T-SQL.

Inital Hypothesis:  Create a PowerShell script that crawls and maps the farm, and outputs the results.  This should examine all the WFE and application servers and the SQL Servers.  If should report on the OS, SQL Server and SharePoint. 

Resolution:  Until someone builds a better flushed out script, I am looking at the local instance of SQL (default) and the SharePoint farm.  This script has been tested to run on a full standalone machine containing both SQL Server and SP2010.
Additional work could be done to crawl all servers in the farm and output the results.  As BGInfo gives the local admin all the network and OS data, this script does it for the application software.

Additional work to do to this script is to loop thru all the SQL instances remotely, display a report or even generate a nice diagram and potentially change the background screen save with all the information on the server containing Central Admin.

In the screen shot above: SQL Server build versions 10.50.2500.0 is SQL Server 2008 R2 SP1; SP2010 build version 14.0.6109.5002  is CU August 2011.
GetSPInfo.ps download.



Updated: 19 July 2012 - Add the line tot he script to show SQL 2012 under the version:
11 {[string]$SqlInfo.SQL_Version = "SQL Server 2012"}

Updated: 24/02/2012 - I had problem in UAT where I was getting stange behaviour and I releaised somebody had changed the time on one of 10 SharePoint servers causing me problems.  The script below verifies the TimeZone for servers in your farm. 
 
 
More Info:
SP2010 build number by Dave Coleman.

Patching a Production SharePoint Farm with CU or SP

Problem: How do you keep a farm up to date but stable whereby patch don’t cause problems to your users or applications in a SharePoint 2010 farm.

Initial Hypothesis: Various software parts are in the SharePoint farm excluding 3rd party add-ins. Windows 2008 R2 gets patch, Cumulative updates and service packs. The 3 products to upgrade from Microsoft are:
• Windows;
• SQL Server; and
• SharePoint 2010.

Microsoft provides 3 mechanisms for patching:
1. Windows Updates are configured to pull down the updates and then prompt or install the updates automatically.
2. Manual Patching by downloading and executing the patch as directed by Microsoft.
3. Windows Server Update Services (WSUS) where a central server pulls all the patches and pushes the patches to the servers.

Resolution: Let patches unless marked as critical from Microsoft be release for a few weeks (4-8 is a good number for me) before implementing them. Roll out to test on a Monday, roll-out the patches on Wednesday and Friday night role out the patches to production.

Patch Windows, SQL & SharePoint regularly.

Windows 2008 must patch the servers on a weekly basis using the WSUS approach in a staggered phased approach as described above and currently done. Also ensure IIS application applicable patches are installed.

SQL patching should be done manually unless there are multiple instances which is only the case in the largest of farms. This should be setup manually but rolled out using WSUS.

SharePoint Patching should not be auto scheduled for deployment. An administrator/Infrastructure should periodically decide on a patch level and apply it via the WSUS service. This can be done manually but as it takes time to perform on each server and as the environment grows this can take time. We also need to watch out for running the configuration as this can take time on big content databases. Also this can be staggered so we install the patch but the content databases are staggered as to when they are updated with the new schema.

Note: An automatic update will install the binary files on the farm servers, but you must complete the software update by running the upgrade on the servers. Technet (http://technet.microsoft.com/library/ff806329(office.14).aspx)

Problem: Updating SharePoint 2010 using Cumulative Updates (CU) ensures your farm has bugs and the latest known security vulnerabilities are closed to attack. Update too early after the patch is release and you risk causing a major disruption to your farm.

Initial Hypothesis: Patches need to be implemented to ensure the farm is secure, stable and as performant as possible. I recommend letting new patches wait for 4 weeks to ensure the major bugs are discovered and potentially corrected by Microsoft.

Since the August 2011 Cumulative Update, Microsoft releases a single package that covers all the SharePoint versions (Foundation, Server), only the applicable patches (.msp files) parts that are needed on your farm are installed. You can still download the CU as a smaller package if you select the Foundation CU. The Cumulative Update contains all hotfixes since SharePoint 2010 was released.

Note that the SharePoint Server 2010 CU contains the SharePoint Foundation CU also, since the August 2011 Microsoft has taken this approach so you only need to install the CU that matches your edition. You no longer need to install the foundation and then the Server edition.

It is recommended that SP1 be installed before the CU however, if you don’t it will include the SP1 fixes. “Software updates include any update, update rollup, service pack, feature pack, critical update, security update, or hotfix”, Technet (http://technet.microsoft.com/en-us/sharepoint/ff800847).

Resolution: Plan (learn), backup (prepare), test, implement and verify (validate) is the basic testing plan suggested by Microsoft.

Deploying updates in a SharePoint Server 2010 environment consists of: downloading the binaries, installing (also referred to as updating) and upgrading by running the configuration wizard (not always). Ensure all servers in the farm (excluding the database servers) have been patched/updated before upgrading (running the configuration wizard (psconfig)).

Validate the CU upgrade:
PS>(get-spfarm).buildversion
Check if psconfig needs to be run:
PS> (get-spserver $env:computername).NeedsUpgrade
if True then
psconfig.exe -cmd upgrade -inplace b2b -force

Ensure the version is the version you are expecting after the patch.
Example of SP2010 SP1 with August 2012 CU:
Major  Minor  Build  Revision
-----  -----  -----  --------
14     0      6126   5000


CA > Upgrade and Migration > Check upgrade status


Update 17/03/2014: SharePoint 2013 with SP1 applied results in 15.0.4569.1000

More Info:
http://blogs.technet.com/b/stefan_gossner/archive/2011/12/14/december-2011-cu-for-sharepoint-2010-has-been-released.aspx
http://technet.microsoft.com/en-us/sharepoint/ff800847
December 2011 CU for SharePoint 2010 - http://support.microsoft.com/kb/2597014
http://technet.microsoft.com/library/ff806329(office.14).aspx
List of SP CU downloads and their build numbers.
PSConfig switches explained by Benjamin Athawes

Example from Benjamin Athawes
Upgrading product version (Major e.g. MOSS 2007 to SP2010 or SP2013 upgrades):

psconfig.exe -cmd upgrade -inplace v2v -wait

Applying a patch (minor e.g. CU or Service Pack):

psconfig.exe -cmd upgrade -inplace b2b -wait