George Bonney's SharePoint Blog

If you want to automatically redirect from HTTP to HTTPS on a SharePoint site, there is an easy way to do it using Alternate Access Mappings.  I have seen suggestions involving IIS redirects which is something that I have done in the past but there is actually no need to do this.

First you must configure your site to use HTTPS so that the public name is the HTTPS name (creating or extending a Web Application using HTTPS).  Next, define an Internal Name in AAM using the HTTP protocol, selecting the same zone as the HTTPS URL's zone.  By doing this, when the user requests HTTP SharePoint will resolve the name to the correct site but will redirect you to the public name which will be HTTPS.

Any comments / suggestions will be appreciated.

Microsoft announced today that Windows 7 and Windows Server 2008 R2 have RTM'd.

http://windowsteamblog.com/blogs/windows7/archive/2009/07/22/windows-7-has-been-released-to-manufacturing.aspx

Having been using Windows 7 RC for the last week (thanks to the unfortunate death of my laptop disk), I can make an educated recommendation to move to Windows 7.  It's quicker and better on memory than Vista and looks great.  The new task bar is awesome, the additional window features like drag based maximise and restore and the window shake are just a few of the great features.

On a related note, Office 2010 CTP is looking great. can't wait for it to RTM!

[Solution below]

I have just discovered that, unlike IE7, in IE8 (and IE7 with the latest updates, I believe – thanks to Peter England for the comment) when you open a new browser it shares its authentication information with other opened instances.  This is VERY bad for anyone trying to sign in as different users at the same time (e.g. using SharePoint's “Sign in as Different User” option) in different browser windows for testing purposes.

This means, for example, if you sign in as SharePoint Administrator in a browser session, then open up a new window using the normal quick launch icon and log in to SharePoint as a basic user, the next time you click a link in the SharePoint Administrator's session, it will switch to being signed in as the basic user.

I have looked for a setting to control this and could not find one but if it does exist and someone spots it then please comment.

[UPDATE]

This may also be affecting IE7 with the latest patches.

[SOLUTION]

Many thanks to Cato Antonsen's for the commented solution.  Use File->New Session to get a separately authenticated browser instance.

Further investigation has revealed that there is also a command-line option “-nomerge” with IE8's iexplore.exe which ensure there are no shared cookies or authentication data but I am not sure about IE7 with the latest patches.

[MORE DETAILED INFORMATION]

http://blogs.msdn.com/askie/archive/2009/05/08/session-management-within-internet-explorer-8-0.aspx

Microsoft have just released a bunch of security fixes for IE in an update – 963027 – which stops you being able to connect to local websites on your server.  You will be prompted to enter a username and password but will receive the standard 401 error after entering credentials 3 times.  There may well be a way to work around this more appropriately, but for now I have removed this update. (see update below).

N.B. This update only applies after reboot and equally only removes after reboot.

To do this go to “Add/Remove Programs”, select the “Updates” checkbox if necessary and find “Windows Internet Explorer 7″.  If you find an entry in here for “963027″ then remove it and reboot (remember, the update is still in effect until you have rebooted).

UPDATE:

Thanks to Matt Tate for pointing out that this is related to a loopback security update.  It turns out that security fix 963027 extends an existing change with regards to the use of the loopback address (127.0.0.1) to include any local web server access (actually – I have only tested this with CNAME DNS entries, it might not happen with A pointers).

See this article for further information:

http://support.microsoft.com/kb/896861

N.B. This also affects indexing – http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=107

SOLUTION:

I am using Method 2 for all personal development and test machines.

********************** FROM MICROSOFT KB ARTICLE ABOVE **********************

To work around this issue, use one of the following methods.

Method 1: Specify host names

Note We recommend that you use this method.

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
   HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0
3. Right-click MSV1_0, point to New, and then click Multi-String Value.
4. Type BackConnectionHostNames, and then press ENTER.
5. Right-click BackConnectionHostNames, and then click Modify.
6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
7. Quit Registry Editor, and then restart the IISAdmin service.

Method 2: Disable the loopback check

Follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
   HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa
3. Right-click Lsa, point to New, and then click DWORD Value.
4. Type DisableLoopbackCheck, and then press ENTER.
5. Right-click DisableLoopbackCheck, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Quit Registry Editor, and then restart your computer.

Cause:

The application pool account does not have rights to create / update timer jobs which is required when enabling the Publishing Infrastructure feature.

Resolution:

There are two options:

1) Temporarily add the application pool account to the farm administrators group, or

2) Run the following command:

stsadm -o activatefeature -name PublishingResources -url http://SITECOLLECTIONURL

I have just resolved a very annoying profile sync problem, although the solution is not 100% clear:

Issue:

Data in users' profiles was not syncing into a Site Collection from the profile database.  Other Site Collections in the same Content Database were syncing fine, but one particular Site Collection was not.  The following errors were added to the logs each time a full sync was attempted (I recommend for testing running “stsadm -o sync -synctiming m:1″ but remember to set it back when you are done):

SyncLog70670000000002 WebApp SharePoint – dasitstassp(0316b518-97dc-4291-b229-94d6723cc40b), ContentDB WSS_Content_dasitstassp(ff034579-1c81-4a60-9f5c-2daa8b21f28d): Exception creating user and/or membership change collection for site – most likely due to falling off the end of the change log (repeated failure to sync this site incrementally?).  Will do full synchronization.  Exception follows: System.NullReferenceException: Object reference not set to an instance of an object.     at Microsoft.SharePoint.SPChangeToken..ctor(String strChangeToken)     at Microsoft.Office.Server.UserProfiles.SiteSynchronizerCollection.GetSynchInfoForSite(SqlDataReader dr, SynchInfo info)    

ProfSynch: Exception attempting to enumerate site d8b1cae6-e169-4f07-ab44-5cb719ac4917 for ContentDB 78c875bf-ffdc-4a14-b0da-2f1328d29dae: System.NullReferenceException: Object reference not set to an instance of an object.     at Microsoft.SharePoint.SPSite.PreinitializeServer(SPRequest request)     at Microsoft.SharePoint.SPSite.GetSPRequest()     at Microsoft.SharePoint.SPSite.get_Request()     at Microsoft.SharePoint.SPSite.get_ReadLocked()     at Microsoft.Office.Server.UserProfiles.SiteSynchronizerCollection.GetSynchInfoForSite(SqlDataReader dr, SynchInfo info)     at Microsoft.Office.Server.UserProfiles.SiteSynchronizerCollection.<get_Elements>d__0.MoveNext()    

2 Possible Causes:

I cannot say for sure what the cause was as it required a timer service restart to make the fix actually work.  Having profiled the database while the profile sync executed, I noticed that it wasn't reading in a user list, or doing anything of relevance in fact, so I figured I would need to restart the timer service to get any changes to take effect i.e. it must cache the user list on first run.  On doing that, the problem went away.  There were two things that might have made it work:

1) “stsadm -o sync -deleteolddatabases 0″

2) There were users in the User Information List that did not exist within the domain. in my case, not just users that were deleted from the domain but users who were in a completely different domain – I had restored a backup from another domain and it caused there to be redundant users in the database from the previous domain – so I deleted those users.

Without re-creating the problem and testing all over again, I cannot be sure what exactly resolved the issue – and I have spent more than long enough on this now!

I hope this helps!

Having just wasted over an hour, I felt it worth sharing my resolution to this gem of an error. Typically, the error is quite generic, but in my case, the problem was caused by including SharePoint controls that relied upon particular querystring entries existing – namely, List=GUID.

So – a bit of background. I am creating an additional list settings page for managing some custom developed stuff – and so I took a copy of an existing list settings page so that I could use the same controls and formatting to get the section effect.  In doing this, I left the main content in there (just to prove that I could see my page and it was happy with my code-behind reference), deployed the layouts page to the 12 folder and then pointed straight to it in the browser.  In theory this should just work – it was, of course, a simple initial test . but – after adding the OK button event handler to my code-behind class, among other things, I ended up with the error above.  After an amount of fiddling around I worked out that the “SharePoint:FormattedStringWithListType” control relies upon the List= querystring entry but doesn't provide any kind of appropriate message to let you know that's what the problem is.

I hope this saves you someone some time!

I have just discovered that it is critical that you keep the length of StaticName values for Fields to 32 or under. anything after this is cropped and the resultant value becomes the InternalName.  This means that if you try and call methods like GetByInternalName or ContainsField passing in your expected name, it will fail.

To help explain this, see the following code, where I am adding fields :

Guid listId = new Guid(Request.QueryString["List"]);
SPWeb web = SPContext.Current.Web;
SPList list = web.Lists[listId];

// LIST OF FIELD GUIDS TO ADD TO THE LIST SPECIFIED IN THE QUERY STRING
// THESE FIELDS ARE DECLARED IN A FEATURE AND HAVE STATIC NAMES LONGER
// THAN 32 CHARACTERS
string[] fieldGuids = new string[] {
    "{36924573-D81E-493e-98E0-9DAF4420FF86}",
    "{33380026-51E7-456e-A601-AEB23C3E98C1}",
    "{63000972-DBBC-4db0-A757-135A32446FC8}",
    "{55935C52-6969-45bb-9757-C71DC3F4BED7}",
    "{7BA783C7-93B9-4b2a-A1E3-B768094B2DDE}",
    "{636E52EE-5635-4f4e-A93C-9FC0D6F0B8BA}",
    "{6D5AB29D-C646-4b61-8F5A-68F443E437CB}"};

web.AllowUnsafeUpdates = true;

foreach (string guid in fieldGuids)
{
    Guid fieldGuid = new Guid(guid);

// HERE WE ARE GETTING THE FIELD WE WANT TO ADD FROM THE SITE COLUMNS
    SPField field = web.AvailableFields[fieldGuid];

// THE STATIC NAME IS MORE THAN 32 CHARS BUT THIS METHOD SEARCHES THE DISPLAY NAME AND, IMPORTANTLY,
// THE INTERNAL NAME – WHICH IS CROPPED AT 32 LONG.  RESULT = FIELD NOT FOUND, WHEN IN FACT IT DOES EXIST
    if(!list.Fields.ContainsField(field.StaticName)) 
        list.Fields.Add(field);
}

list.Update();

N.B. if you intend to use this code then always remember to put code like this in a try/catch/finally so you can reset the web.AllowUnsafeUpdates value back to false.

http://www.connectionstrings.com

This site seems to have to have all of them… top site!