I wanted to note that I put this out on our TechNet Wiki Page also and may contain more current\revised data so please check there as well!

I have seen several inquiries out here on the internet, along with a few blogs where people have experienced issues when trying to slipstream SharePoint 2013 to the latest Cumulative Update, ex: October 2013 CU. As most of you may know, in order to get to the latest build, you must install March 2013 PU as a pre-requisite before you can get October 2013, December 2013 CU applied. In theory, the slipstreaming process consists of

1. Downloading the PU\CU
2. Extracting the contents of the PU\CU
3. Move them into the “updates” folder in your SP installation folder and GO

The problem we have seen with some of our customers in SP 2013, is they extract March PU, October 2013 CU along with the contents of the “ubersrv_1.cab”, and then copy these into the “updates” folder. They then install SharePoint with the expectation that when the farm builds out, it would reflect the build of the latest update ( ex: 4551.1000 for October ) but in reality it shows the farm build to be RTM still.

Note: I am going to stop right here for a minute and advise that if you want to install a base install with the latest builds, I would advise to go ahead and download a slipstreamed build of “SP 2013 with SP1” ( from MSDN ) OR download SP1, extract its contents ( using “officeserversp2013-kb2817429-fullfile-x64-en-us.exe /extract:C:\SP1_extract” ) and just build your slipstream this way. SP1 includes all of the PU\CU updates since the release of RTM up through December 2013 CU & January 2014 PU

If you decide you are not ready to do this and still want to slipstream March 2013 PU + “subsequent CU”, then I am going to outline how you can successfully do this. I would also like to preface this with the fact that this is primarily applicable if you are slipstreaming March PU + “subsequent CU” with the English language only.

Here we go! ( I am using October 2013 CU as my “subsequent CU” in my steps here )

I want to provide a little background on WHY just extracting and putting into “updates” folders will not work. Since March 2013 PU is a pre-requisite to installing CU’s, SP must know that March PU has been applied before it can apply the October 2013 CU. This is known as a new baseline called “SP0” How does it know its applied when this is a brand new install? It doesn’t, so it does not apply the updates at all and this is why you see the farm build out at RTM still. In order to get these updates to “apply” we have to do a little manipulation to the .msp files to “trick” SP into applying the March 2013 PU updates and then the later CU .msp will be applied.

Start By Downloading the following:

March 2013 Public Update: 

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

September 2013 Update:

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

October 2013 Cumulative Update:

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2825647

·         Once you have these downloaded and saved to C:\Hotfix\<UpdateDir>, you will want to extract each one..

·         Starting with March 2013 CU, I run the following command to extract the msp’s from the .exe

c:\Hotfix\March 2013 PU>ubersrvsp2013-kb2767999-fullfile-x64-glb.exe /extract:"C:\Hotfix\March 2013 PU\extracted"

·         Like I mentioned in a previous email, in order to get to the October 2013 CU or later builds, like October or December, the server needs to think it has a new baseline, what we refer to as SP0, before it will apply those binaries during the install.

·         In order to trick the server into thinking this, we have to do some manipulation to the March 2013 PU msp’s and rename them before putting them into the “updates” folder..

·         Once you have extracted them, there should be 16 of these files, we will want to rename them to have a “_” as a prefix and a “-SP0” as a suffix

·         I used a tool called “Bulk Rename” to do this, but this is what the file names should look like

_acsrvwfe-x-none-SP0.msp

_coreserver-x-none-SP0.msp

_eduwfe-x-none-SP0.msp

_ifswfe-x-none-SP0.msp

_lpsrvwfe-x-none-SP0.msp

_oserver-x-none-SP0.msp

_osfserver-x-none-SP0.msp

_ppsmawfe-x-none-SP0.msp

_pptserver-x-none-SP0.msp

_sms-x-none-SP0.msp

_sts-x-none-SP0.msp

_vsrvwfe-x-none-SP0.msp

_wasrvwfe-x-none-SP0.msp

_wdsrv-x-none-SP0.msp

_wss-x-none-SP0.msp

_xlsrvwfe-x-none-SP0.msp

·         Once you have renamed these, you can now place them into your “updates” folder ( C:\Apps\SP2013\October4551\Updates )

·         Next extract the September 2013 Update

c:\Hotfix\September 2013 Update>svrproofloc2013-kb2760250-fullfile-x64-glb.exe /extract:"C:\Hotfix\September 2013 Update\extracted”

·         Since this is English Only, we will copy the following file and place it into the “updates” folder”

svrproof-en-us.msp

·         Now lets move to the October 2013 CU

·         Keep in mind this patch has the “ubersrv2013-kb2825647-fullfile-x64-glb.exe” but it also has a “.com” file and the “ubersrv_1.cab” file…

·         We will want to extract the files from the “.exe” and the “.cab” file..

c:\Hotfix\October 2013-4551.1005>ubersrv2013-kb2825647-fullfile-x64-glb.exe /extract:"C:\Hotfix\October 2013-4551.1005\extracted"

·         To extract the .cab files, just go into the cab file, select All and then extract to "C:\Hotfix\October 2013-4551.1005\cab_extracted”

·         Once you have extracted all of these files, and since this is English Only, we want to go find the files ending in “en-us.msp” AND “x-none.msp”

From the “C:\Hotfix\October 2013-4551.1005\extracted”

acsrvmui-en-us.msp

coreservermui-en-us.msp

edumui-en-us.msp

ifsmui-en-us.msp

lpsrvmui-en-us.msp

osfservermui-en-us.msp

ppsmamui-en-us.msp

pptservermui-en-us.msp

smsmui-en-us.msp

acsrvwfe-x-none.msp

coreserver-x-none.msp

eduwfe-x-none.msp

ifswfe-x-none.msp

lpsrvwfe-x-none.msp

osfserver-x-none.msp

ppsmawfe-x-none.msp

pptserver-x-none.msp

sms-x-none.msp

sts-x-none.msp

vsrvwfe-x-none.msp

wasrvwfe-x-none.msp

wdsrv-x-none.msp

wss-x-none.msp

xlsrvwfe-x-none.msp

From the “C:\Hotfix\October 2013-4551.1005\cab_extracted”

acsrvmui-en-us.msp

wssmui-en-us.msp

pptserver-x-none.msp

sts-x-none.msp

wdsrv-x-none.msp

·         Put these into the “updates” folder

·         At this point, you should have 46 files in the folder.

You should be able to install SP at this point and it reflect the correct build when the farm is built. Setting this baseline by renaming the Marm 2013 PU msp’s is the key point here in getting this to work correctly. Our source code knows that the files with “_” should be installed first and then we can apply the later CU’s. This takes a bit of work to get this done, but it can be done. Again, if you want to just download SP1, you should be able to extract these files and put them into “updates” or download a pre-built SP1 install.

Hope this is helpful!

It’s been a while since I have posted anything, so hello again! :) I have been meaning to post this for some time, but time seems to be my enemy.

I worked with a customer a while back that ran into a scenario where they were using a standard “Search Service Application” within the SharePoint 2010 and they were crawling a non-SharePoint, Apache based wiki site, called “MediaWiki.” MediaWiki will allow you to create a new page with pretty much any name you would like.

Example:

http://www.contoso.com/mediawiki/wiki.test.page

When their content source would go out and crawl this site, it would not crawl and index this new page, so it was not showing up in search results.

By default, within the SSA (Search Service Application) Administration page we have a link called “File Types”, and this page controls what File Extensions we will and will not crawl.

By Default, within a SharePoint SSA, NOT FAST 4 SharePoint 2010, this “File Types” list is an “Include” list, so anything NOT in this list will not get crawled. Here in lies the problem for my customer. Being that end users had the capability to create a page with any name, the “extensions” could vary from anything. Trying to control what extensions will need to be in this list would be nearly impossible and require a lot of man hours to even try to maintain this!

Here is where my customer turned to Microsoft support, to look for a solution or a potential work around. The solution we provided the customer was to utilize PowerShell and manually “flip” this “Include” list to an “Exclude” list, so that the SSA will crawl any extension, except for what is now in the “File Types” list.

Here are the steps to accomplish this task:

Flip the List to an Exclude List

• Open PowerShell Management Shell for SharePoint with elevated rights, or if you have PowerShell ISE, you can use this also
• Execute the following:

$sa = Get-SPServiceApplication | where { $_.ApplicationClassId -eq "52547a3d-66ed-468e-b00a-8c4a3ec7d404" }

$sa.SetIsExtensionIncludeList($sa.GetVersion(),0);

• This will flip the SSA to make it an Exclude list
• Restart OSearch14 via services.msc console or with command line

net stop OSearch14

net start OSearch14

Keep in mind now that this list is now an “Exclude” so anything in here will no longer be crawled..

We then utilized additional PowerShell to clean out all the existing “File Types” and allowed the customer to start with a clean slate:

Remove the existing file types

• Again using PowerShell Management Shell or PowerShell ISE
• Execute the Following: (make sure you replace the “SSA” with the name of your Search Service Application)

$ssa = Get-SPEnterpriseSearchServiceApplication -Identity "SSA" $content = New-Object Microsoft.Office.Server.Search.Administration.Content($ssa)

$extList = $content.ExtensionList

$list = New-Object System.Collections.ArrayList

foreach ($ext in $extList)

{

$list.Add($ext);

}

for ($i = 0; $i -lt $list.Count; $i++)

{

$ext = $list[$i]

$ext.FileExtension

$ext.Delete()

}

Below is a list of Extensions that FAST includes OOB.. Feel free to add these in as needed.. I just wanted to give you a list of extensions that MS uses as “excludes”

I have tested this within our lab, using a clean slate, and it worked. Please let me know if you have any questions. Thanks!

I believe this should transfer over to SP 2013 also…

' THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF

' ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO

' THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A

' PARTICULAR PURPOSE.

' Copyright (C) Microsoft Corporation, 2013

Hello Everyone..!! It’s been a little while since I last posted. There have been several inquiries on this issue and it also appears to be a common query among search engines, peers, and friends in the SharePoint community.  Since SharePoint 2010 is growing in popularity, I am going to put emphasis on this version of the product within this blog.

The issue at hand is when directly linking Office Documents within your site, even though anonymous access is enabled, you are still prompted for credentials and if you cancel, an error is received:

401 Unauthorized

Ideally, as an anonymous user, you should be able to open this document, without being prompted for credentials and without getting a “401 Unauthorized”

Initially this was a common problem when direct links were added to .xlsx files.  Findings show when a Document library containing .xlsx and .xls files are directly linked to URL’s, the .xlsx fails and the .xls succeeds.

We are now seeing similar behavior in SharePoint 2010 where Office Web Apps have been installed on the SharePoint servers.

So… Why do we get this error in the first place…?

• In SharePoint 2007 and 2010, “.xlsx” extensions are mapped to the “xlviewer.aspx” page, via a file called, “serverfilesExcelServer.xml”
• This page actually requires an additional permission, “OpenItems”, in order for it to successfully render a “.xlsx” file.
• In SharePoint 2010, when you install Office Web Apps, we add additional file handlers that now map other extensions, like .doc and .docx, to pages, like “wordviewer.aspx”.
• These pages also require the “OpenItems” permission that anonymous users do NOT have.
• By default, Anonymous Users do NOT have this “OpenItems” permission and this is what causes the failure to open or render the files

Note: There have been numerous postings on the web advising simply remove the mapping within the above mentioned XML file, but this will put you into an unsupported state, so it is recommended NOT to do this.

If you were to look at the ULS logs while trying to access a directly linked document, you will see something like this:

09/19/2011 16:20:59.87   w3wp.exe (0x3164)             0x3DF4  SharePoint Foundation        General   ewn8      Verbose                OriginalPermissionMask check failed. asking for 0x00000021, have 0x1000031041             f22f656c-a188-4a4c-9b41-8deeb6b934bd

And this is what the Permission Mask(s) translates to:

OriginalPermissionMask check failed. asking for 0x00000021, have 0x1000031041

0x00000021 = ViewListItems, OpenItems

0x1000031041 =  ViewListItems, ViewVersions, ViewFormPages, Open, ViewPages, UseClientIntegration

As we can see, we are asking for “OpenItems” and we do not have it…

KB2498047 was published to address the “.xlsx” extension, but it will also address additional Office Doc extensions. There are 3 possible work arounds, but I am going to focus on the solution provided that utilizes PowerShell to add the “OpenItems” permission to our SPBasePermissions for anonymous users. This PowerShell will assist in adding “OpenItems” to a single web….

So what if I have a Site Collection and this site collection contains 2000 + webs?

What if some of these webs inherit permissions from the parent web, but a lot of them actually contain unique permissions? (They are still anonymous access webs, they just contain a Unique Permission Scope)

Do I need to execute this PowerShell for each web in my Site Collection…?

If your Site Collection had 2000+ webs and they all inherited from the parent web, then you could execute the PowerShell at the root Site Collection, or Top-Level Site and be done. But since you may have 2000+ webs that have unique permission scopes, we would need to iterate through the entire Web Application and set this “OpenItems” permission on our AnonymousPermMask64.

We put together a PowerShell script that would do this for you as well as the script to undo that permission add:

NOTE: Giving anonymous "OpenItems" permission allows anonymous users to have view source rights to certain files that could potentially contain sensitive info.

NOTE*: That you should only do this if you understand & accept the security implications.

To Set “OpenItems” across an entire Web Application:

·         Once the ps1 is saved, pass the URL as the $arg, Ex:

.\AnonPermMask64_OpenItems_Add.ps1 “http://www.somesite.com”

·         Code:

Add-PSSnapin Microsoft.SharePoint.PowerShell

 

[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

 

 

    $siteUrl = Get-SPWebApplication $args[0] | Get-SPSite -limit All;

 

    foreach($url in $siteUrl)

   

    {

        write-host $url.url;

        $site = New-Object Microsoft.SharePoint.SPSite($url.url);

       

        foreach($webs in $site.AllWebs)

        {

           

            $enumPerms = [Microsoft.SharePoint.SPBasePermissions];

 

           

            if ($webs.HasUniquePerm)

            {

           

            Write-Host 'Setting Attribute for '$webs.url;

           

            $webs.AnonymousPermMask64 = $webs.AnonymousPermMask64 -bor $enumPerms::OpenItems

            $webs.Update();

           

            Write-Host 'Attribute for '$webs.url' has been set';

           

            } else

           

            {

           

            Write-Host 'Setting Attribute for '$webs.url;

            Write-Host 'Site Inherits Permission from Parent'

           

            }

        }

       

        $site.Dispose();

     } 

       ##end of the for each loop

 

write-host 'Finished';

To Remove The “OpenItems” across the Web Application:

·         Code:

Add-PSSnapin Microsoft.SharePoint.PowerShell

[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

    $siteUrl = Get-SPWebApplication $args[0] | Get-SPSite -limit All;

    foreach($url in $siteUrl)

    {

        write-host $url.url;

        $site = New-Object Microsoft.SharePoint.SPSite($url.url);

        foreach($webs in $site.AllWebs)

        {

            $enumPerms = [Microsoft.SharePoint.SPBasePermissions];

            if ($webs.HasUniquePerm)

            {

            Write-Host 'Setting Attribute for '$webs.url;

            $webs.AnonymousPermMask64 = "ViewListItems, ViewVersions, ViewFormPages, Open, ViewPages, UseClientIntegration"

            $webs.Update();

            Write-Host 'Attribute for '$webs.url' has been set';

            } else

            {

            Write-Host 'Setting Attribute for '$webs.url 'back to default BasePermissions';

            Write-Host 'Site Inherits Permission from Parent'

            }

        }

        $site.Dispose();

     } 

       ##end of the for each loop

write-host 'Finished';

I hope you found this helpful. There is some information not covered here in order to keep it concise. If you have any questions, please feel free to post and I will address them as soon as possible. Thanks!

Hello Everyone… Its been a while since I wrote a blog. I wanted to share some good information on using stsadm -o migrateuser after an Account has been deleted within Active Directory and then re-created with the same Account Name.

Consider the following Scenario:

• We have a user that has an account in Active Directory with account name = DOMAIN\jdoe
• This user has a SID = S-1-5-21-1461310-839809092-932994037-4144
• User, DOMAIN\jdoe, has been granted permissions to some 300 site collections
• Its determined that this user account is having some permission issues within the Domain so the AD account is deleted. :)
• The account is now re-created again within AD and given the same account name, DOMAIN\jdoe
• Except now a new SID is created within AD
• SID = S-1-5-21-1461310-839809092-932994037-4147
• The problem we now have is that because this user already had permissions on some 300 sites that are associated with the Old SID
• The account name may be the same but when this user tries to Access Any of the Sites, there is a SID mismatch and the user now gets an Access Denied:

• The UserInfo table is the table on Each Content Database that holds the users login information as well as the SID. These are stored in the following two columns within the UserInfo Table

LoginName

tp_systemID

So the question is….. How do we get the new SID from AD into the UserInfo table. While this can be done with creating a  temporary account in AD and doing some  "stsadm -o migrateuser" flipping from Temp Account to Valid Account and vise versa,  I have found that we can achieve this task by passing the same value for the "-oldlogin" & "-newlogin" and setting the "-ignoresidhistory" switch on our "stsadm -o migrateuser" command. So this is basically what you would do:

stsadm –o migrateuser –oldlogin DOMAIN\jdoe –newlogin DOMAIN\jdoe –ignoresidhistory

What this should do is flip the SID, or "tp_SystemId" in the UserInfo table to be the new account SID from AD and your user should now have access to all 300+ sites again.

Happy Migrating!!

I have seen a couple of cases where then end users where having an issue with the "Related Sites" search scope within a SharePoint Portal Site. By default, when you create a Collaboration Portal, the following 3 Search Scopes show up when you first load the page:

This Site: Home
All Sites
People  

These are the 3 main scopes that get pulled in from the SSP within a SharePoint farm. "This Site" would be considered a Contextual Scope and is specific to searching for content only within the context of that site. If you were to browse to the "Related Links scope settings" within a site and add an addtional search scope, based on another URL, like http://microsoft.com, and then re-compile your scopes manually or let the SSP scope compilation complete automatically (every 15 minutes by default). When you go back to the home page your site, you should see a "Related Sites" search scope in the drop down. This is all good if you intend to utilize this search scope, but the issue comes to surface when you decide that you no longer want to have any "Related Sites" search scopes within that site.  So lets say you perform the following actions to remove the related links:

• Browse to the site you want to remove the Related Links from via, http://fqdn.domain.com/_layouts/RelLinksScopeSettings.aspx
• Click on the Selected Links you want to remove ( all in this case) and for each one, you click on "Remove"
• You click on OK and suspect all is good.
• Wait for the Scopes to compile on their own or manually force the compilation via http://servername:6000/ssp/admin/_layouts/searchsspsettings.aspx and then click on "Update Scopes"
• reset IIS to clear the cache
• Browse back to the site and you notice the "Related Sites" is still in the drop down.

At this point you would expect the "Related Sites" to disappear, so you browse back to the /_layouts/RelLinksScopeSettings.aspx page and see the words "emptytext" in the "Available Links"section of the page. This gives the impression that a scope exists in the site so this is why the "Related Sites" scope is still present in the search drop down.

So you ask, how can I get rid of this at this time? It is not really causing any real problem other than maybe some confusion for the end users who are trying to search for information within this site. While there is not a direct way through the UI to remove this from the search scopes, I can provide you some sample Object Model code that you or a developer can compile and run against the site URL and get that to disappear from the drop down. Again this is Sample Code and has no warranty and is not supported by Microsoft. This code will basically identify the WebID within the content database for the site URL you want to remove the "related sites" link from and then correleate that GUID with the Scopes in the SSP DB and delete the item from the database. After this is completed, it is necessary to go ahead and update the scopes and then do an IISReset in order to flush the compiled pages from memory. Below is the Sample Code you can use to remove the "Related Sites" scope from a site"

 =======================================================================

Sample Code

·         We basically created a Form Box for the GUI 

·         Then compile the code below:

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

using System.Collections;

using Microsoft.SharePoint;

using Microsoft.Office.Server;

using Microsoft.Office.Server.Administration;

using Microsoft.Office.Server.Search;

using Microsoft.Office.Server.Search.Administration;

namespace scopedelete

{

     public partial class Form1 : Form

    {

        public Form1()

        {

            InitializeComponent();

        }

         private void button1_Click(object sender, EventArgs e)

        {

            if (textBox1.Text.Trim() == "")

            {

                MessageBox.Show("Please enter the root web URL.");

            }

            else

            {

                SPSite site = new SPSite(textBox1.Text);

                SPWeb myweb = site.OpenWeb();

                Guid mywebid = myweb.ID;

              //  MessageBox.Show("webid : " + mywebid.ToString());

                Uri siteuri = new Uri(site.Url);

                Microsoft.Office.Server.ServerContext myservercontext = Microsoft.Office.Server.ServerContext.GetContext("SSP");

                SearchContext scontext = SearchContext.GetContext(myservercontext);

                Scopes sspscopes = new Scopes(scontext);

                ScopeCollection allscopes = sspscopes.AllScopes;

                Scope myscope = null;

                Scope MydeleteScope = null;

                IEnumerator myscopeenum = sspscopes.AllScopes.GetEnumerator();              

                for (int i = 0; i < allscopes.Count; i++)

                {

                    while (myscopeenum.MoveNext())

                    {

                        myscope = (Scope)myscopeenum.Current;

                      //  MessageBox.Show(myscope.Name); 

                        if (myscope.Name == mywebid.ToString())

                        {

                            MydeleteScope = myscope;

                            break;

                        }                       

                    }

                }

                if (MydeleteScope == null)

                {

                    MessageBox.Show("Related sites scope for site " + myweb.Name + "(" + textBox1.Text + " ) does not exist.");

                }

                else

                {

                    MydeleteScope.Delete();

                    MessageBox.Show("Related sites scope for site " + myweb.Name + "( " + textBox1.Text + " ) deleted successfully");

                }

            }

        }

        private void Form1_Load(object sender, EventArgs e)

        { 

        } 

     }

   }

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

   ** Please note that where I have highlighted “SSP” you will need to replace that value with the name of your SSP 

' THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF

' ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO

' THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A

' PARTICULAR PURPOSE.

' Please stress test this code before deploying it in a production environment.
' This is intended as a sample of how code might be written for a
' similar purpose. This code has not been tested.  This code is
' also not to be considered best practices or prescriptive guidance. 
 
' It is highly recommended that you FULLY understand what this code is doing
' and use this code at your own risk.

' Copyright (C) Microsoft Corporation, 2009 

·         Once this is compiled and executed browse to your SSP Admin Site

·         Click on Search Settings:

·         Find the Scopes Section and click on “Start Update Now”

·         Once that has been updated go into your WFE server(s) and recycle the application pools for the Web App you just executed this against.

After the page has been rendered again, you should see that the “Related Sites” option is no longer present in the Search Drop Down Box

=======================================================================  

To confirm that the scope has been deleted, you can open up SQL Server Management Studio and then run the following queries to see that the GUID for that scope has been removed from the SSP Database.

• First you would need to get the WebId from the content DB that you ran the code against
• Open SQL Server Management Studio and create a New Query
• In the drop down, next to the "execute" function in the toolbar, make sure you have the Content Database select
• Then run the following:

• Identify the Id where root of that site exists.
• Copy this GUID and put it into notepad
• Then create a new query and this time make sure the SSP DB is selected, not the Search DB, but the SSP DB
• Then run the following:

          select * from MSSScopes

• If the GUID is still present in that table, then you have not successfully removed the scope. If it is no longer present, then the "Related Sites" scope should no longer be there when the Scopes are Updated and IIS has been reset.

 I hope this helps in the event you want to get rid of that "Related Sites" scope within your Search Drop Down!