Feeds:
Posts
Comments

Archive for the ‘SP2010 Administration’ Category

We resolved an issue today where a SharePoint Admin mistakenly deleted an out-of-the-box SharePoint Timer Job. Many of the “resolutions” we found while searching for a fix to the “uh oh!” involved the recreation or restoration of several–if not all–of the timer jobs which come with SharePoint. Honestly, that made me nervous because I’d rather not be touching something that is working just fine.

Knowing that custom timer jobs get attached through a few lines of code, I figured the same could probably be done to fix our single missing timer job. And, sure enough, it could! Here’s the PowerShell we used to restore the mistakenly deleted Information management policy job:

[System.Reflection.Assembly]::Load("Microsoft.Office.Policy, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c");
$wa = get-spwebapplication http://webappurl;
[Microsoft.SharePoint.SPSchedule] $schedule = [Microsoft.SharePoint.SPSchedule]::FromString("weekly at fri 23:00:00");
[Microsoft.Office.RecordsManagement.Internal.PolicyUpdatesJobDefinition] $policyJob = New-Object "Microsoft.Office.RecordsManagement.Internal.PolicyUpdatesJobDefinition" ($wa);
$policyJob.Schedule = $schedule;
$policyJob.Update($true);

To restore your mistakenly deleted job, all you need to do is find the assembly which contains the job (“Microsoft.Office.Policy” above) and the class used to instantiate the SPTimerJob (“Microsoft.Office.RecordsManagement.Internal.PolicyUpdatesJobDefinition” above). Substitute your assembly and class as needed above. Of course, you’ll want to use your web application URL instead of “webappurl.”

Mark Arend has a wonderful post on MSDN Blogs about the strings for SPSchedule.FromString.

Advertisements

Read Full Post »

Okay, so apparently there is a difference between SharePoint PowerShell and Windows PowerShell ISE. I was attempting to write a script based off of Deploy by using DBA-created database (SharePoint Server 2010) (yah, 2010 guidance for 2013–apparently the 2013 guidance isn’t yet available). Naturally, I didn’t want to just take the script at face value and run it without understanding it. So, I started walking through it one line at a time to see the results. What better tool to use when writing and debugging PowerShell than the PowerShell ISE? (That’s a rhetorical question! I’m sure many of you have other tools vastly superior.) Naturally, you have to Add-PsSnapin Microsoft.SharePoint.PowerShell when using the ISE, but the line by line debugging is well worth it to me. Unexpectedly, when I got to the New-SPEnterpriseSearchServiceApplication line, I got an error: “Requested registry access is not allowed.”

PS C:\> $searchApp = New-SPEnterpriseSearchServiceApplication -Name $searchAppName -ApplicationPool $appQueryPool -AdminApplicationPool $appAdminPool -DatabaseServer $databaseServer -DatabaseName $adminDB
New-SPEnterpriseSearchServiceApplication : Requested registry access is not allowed.
At line:1 char:14
+ $searchApp = New-SPEnterpriseSearchServiceApplication -Name $searchAppName -Appl ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (Microsoft.Offic...viceApplication:NewSearchServiceApplication) [New-SPEnterpriseSearchServiceApplication], SecurityException
+ FullyQualifiedErrorId : Microsoft.Office.Server.Search.Cmdlet.NewSearchServiceApplication

Okay, that’s weird! After discovering how to use the Process Monitor to figure out what account was having troubles reading the registry, I still didn’t have any solution. Everything looked fine.

On a whim, I decided to try the lines of script in the SharePoint 2013 Management Shell… No problem.

So, moral of the story: If you’re having troubles with using cmdlets in Windows PowerShell ISE, try the SharePoint 2013 Management Shell. At least with New-SPEnterpriseSearchServiceApplication, there is a difference.

Update, 6/6/2013:
Sometimes there are gotchas, and this one got me. You need to be sure to run Windows PowerShell ISE as an Administrator just as you would SharePoint 2013 Management Shell. After some feedback from a SharePoint 2010 Master, I got to thinking I may have overlooked something. Appears I had! The New-SPEnterpriseSearchServiceApplication cmdlet did not give any error when I ran it from Windows PowerShell ISE as an Administrator. Unfortunately for me, the rest of the script provided in the 2010 guidance can’t be used, anyways, because several of the cmdlets don’t exist in 2013.

Read Full Post »

Spring cleaning is coming early to my SharePoint 2010 farm. With SharePoint 2013 right around the corner and a huge push to cleanup farms before doing the upgrade, I’ve taken the initiative to take out the garbage which has been accumulating for several years. I’m finding all sorts of rubbish, too: Fab 40 (yes, we still had remnants of it installed and running in SharePoint 2010); other no-longer used or supported features; unused sites; unused SharePoint groups; groups with users who no longer exist; and even audiences that were created and never used. Just like at home where I’m doing the winter pruning and de-cluttering the basement, the garbage and recycle cans have been filled to the brim many a time during this cleanup project. Hopefully, I’ll soon be able to blog about removing some of the other rubbish mentioned, but today I want to focus on those unused audiences.

I’ve ran across several questions posted on various forums about finding where audiences are being used or even how they are stored, but the answers given are generally missing or, at best, vague. Being that I needed a real solution, I got to task. The answer wasn’t simple: Audiences are used and stored in three different ways (that I’ve been able to identify–please let me know if I missed any!):

  1. You can specify an audience on a web part.
  2. You can set an audience on a list item.
  3. You can designate an audience for a navigation item (i.e. Top Nav Bar, Quick Launch, Global Navigation, or Current Navigation).

Thus, to find where an audience is used, you have to check all of these different areas. Not even the databases store this type of data in one place (see “Where Target Audience settings data is stored in SharePoint 2010?” on the Microsoft forum for more info on the storage of a SPListItem’s audience).

At this point, I’ve got to say, “I love PowerShell!” It comes to the rescue here, yet again. (Without it, I’d be relegated to writing a console app.) After studying and understanding the below PowerShell script, copy and paste it into a file (I named mine “Get-AudienceTargets.ps1” and saved it on the desktop).

Param(
	[parameter(Mandatory=$True,Position=1)]
	[String]
		$WebApplicationURL
)

if((Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction
SilentlyContinue) -eq $null){
    $ver = $host | select version
    if ($ver.Version.Major -gt 1) {
        $Host.Runspace.ThreadOptions = "ReuseThread"
    }
    Add-PsSnapin Microsoft.SharePoint.PowerShell
    Set-location $home
}

$psShared = [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared;

$allSites = Get-SPWebApplication $WebApplicationURL | Get-SPSite -Limit ALL;

[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.Audience");
$spcontext = [Microsoft.Office.Server.ServerContext]::GetContext($allSites[0]);
$audmanager = New-Object Microsoft.Office.Server.Audience.AudienceManager($spcontext);
$audiences = $audmanager.Audiences;

function GetAudienceNames([string]$audienceFilter){
    $au = $audienceFilter.Split(";;");
    if($au[0] -ne "") {
        $au[0].Split(',') | foreach-object { 
            if($audiences.AudienceExist([Guid]$_)) {
                $audienceFilter = $audienceFilter.Replace($_, $audiences[[Guid]$_].AudienceName); # $r += $audiences[[Guid]$_].AudienceName + ", ";
            }
        }
    }
    return $audienceFilter.Replace(";;","|");
}

function GetLWPM($w, [string]$url){
    try {
        $wpm = $w.GetLimitedWebPartManager($url, $psShared);
    }
    catch {
        write-host ("Error getting limited web part manager for " + $url) -foreground red
    }
    return $wpm;
}

write-output ("Web|Path|Web Part Title|SharePoint Audience|Audience AD LDAP Path|SharePoint Group");

$allSites | get-spweb -limit all | foreach-object {
	$w = $_;
    try {
	$w.Files | where-object {$_.ServerRelativeUrl -like "*.aspx"} | foreach-object {
		$wpm = GetLWPM -w $w -url $_.ServerRelativeUrl; #$w.GetLimitedWebPartManager($_.ServerRelativeUrl, $psShared);
        if($wpm){
            try{
		      $wpm.WebParts | where-object {$_.AuthorizationFilter -gt ""} | foreach-object {
		          write-output ($w.Url + "|" + $_.ServerRelativeUrl + "|" + $_.Title + "|" + (GetAudienceNames -audienceFilter $_.AuthorizationFilter));
		      }
            } finally {
                $wpm.Dispose();
            }
        }
	}
	$w.Lists | where-object { !$_.Hidden } | foreach-object {
        if($_ -is [Microsoft.SharePoint.SPDocumentLibrary]){
    		$_.Items | where-object {$_.Url -like "*.aspx"} | foreach-object {
                $item = $_;
                $iUrl = ($w.Url + "/" + [System.Web.HttpUtility]::UrlPathEncode($_.Url));
    			$wpm = GetLWPM -w $w -url $iUrl; # $w.GetLimitedWebPartManager($iUrl, $psShared);
                if($wpm){
                  try{
    			    $wpm.WebParts | where-object {$_.AuthorizationFilter -gt ""} | foreach-object {
    			 	   write-output ($w.Url + "|" + $item.Url + "|" + $_.Title + "|" + (GetAudienceNames -audienceFilter $_.AuthorizationFilter));
    			    }
                  } finally {
                    $wpm.Dispose();
                  }
                }
            }
        }
        if ($_.Fields.ContainsFieldWithStaticName("Target_x0020_Audiences")) {
            $_.Items | foreach-object {
                if ($_["Target_x0020_Audiences"] -ne $null){
                    write-output ($w.Url + "|" + $_.Url + "|" + $_.Title + "|" + (GetAudienceNames -audienceFilter $_["Target_x0020_Audiences"]));
                }
            }
        }
	}
    if([Microsoft.SharePoint.Publishing.PublishingWeb]::IsPublishingWeb($w)){
        $pweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($w);
        $pweb.Navigation.GlobalNavigationNodes | where-object { $_.Properties.ContainsKey("Audience") -and $_.Properties["Audience"] -ne "" } | foreach-object { 
            write-output ($w.Url + "|[GlobalNavigationNodes]|" + $_.Title + "|" + (GetAudienceNames -audienceFilter $_.Properties["Audience"]))
        }
        $pweb.Navigation.CurrentNavigationNodes | where-object { $_.Properties.ContainsKey("Audience") -and $_.Properties["Audience"] -ne "" } | foreach-object { 
            write-output ($w.Url + "|[CurrentNavigationNodes]|" + $_.Title + "|" + (GetAudienceNames -audienceFilter $_.Properties["Audience"]))
        }
    } else {
        $w.Navigation.QuickLaunch | where-object { $_.Properties.ContainsKey("Audience") -and $_.Properties["Audience"] -ne "" } | foreach-object { 
            write-output ($w.Url + "|[QuickLaunch]|" + $_.Title + "|" + (GetAudienceNames -audienceFilter $_.Properties["Audience"]))
        }
        $w.Navigation.TopNavigationBar | where-object { $_.Properties.ContainsKey("Audience") -and $_.Properties["Audience"] -ne "" } | foreach-object { 
            write-output ($w.Url + "|[TopNavigationBar]|" + $_.Title + "|" + (GetAudienceNames -audienceFilter $_.Properties["Audience"]))
        }
    }
    } finally {
        $w.Dispose();
    }
}

Next, execute the script from a PowerShell command prompt (the astute may notice this doesn’t necessarily have to be the SharePoint Management Shell–when writing scripts, I like to use the PowerShel ISE but it doesn’t normally load the SharePoint snapin), supplying the URL of the web application you want to check.

The script will iterate through all of the content in the web application and output pipe-delimited (‘|’) text with a header and the data for the audience data it finds such as:

Web|Path|Web Part Title|SharePoint Audience|Audience AD LDAP Path|SharePoint Group
http://sppaule|Shared Documents/Test-WebPartPage.aspx|Shared Documents|Admins||
http://sppaule|SitePages/Test-WikiPage.aspx|Shared Documents|Admins||
http://sppaule/blank|Lists/Tasks/2_.000|Test2|Admins||
http://sppaule/sites/hp|Pages/default.aspx|Content Editor|7788a621-ec5a-4656-8976-537e29a6d85c,0223cb9a-f465-4598-ae0f-84bc590e0b53,eab8c97d-fcdf-427a-93f7-a929ce24a589,320bc09a-31fb-4350-87d1-37d2cdffaf01||
http://sppaule/sites/hp|Pages/default.aspx|Utah Weather|Admins||
http://sppaule/sites/hp|[GlobalNavigationNodes]|Dev||CN=Team PaulE,OU=Distribution Groups,OU=Corp,DC=ewert,DC=fam
CN=Gen1,OU=Distribution Groups,OU=Corp,DC=ewert,DC=fam|Gen2
http://sppaule/sites/hp|[GlobalNavigationNodes]|HR|0a16b96d-b445-4f05-a6fd-0db9a31fcbad||
http://sppaule/sites/hp|[GlobalNavigationNodes]|Teams|0a16b96d-b445-4f05-a6fd-0da9d31fcbad||
http://sppaule/sites/hp|[CurrentNavigationNodes]|Lists|Admins||

There you have it: A listing of where audiences are used! Those GUIDs that are remaining in the “SharePoint Audience” column of the output are audiences that no longer exist. You’ll need to use the information provided to navigate to the content and update the audience settings for that object (list item, navigation item, or web part).

I like to capture the output to a text file (in the case below, the script will check the web application at http://sppaule for audiences and output will be stored in a file named “audTargets.txt” on my desktop):

PS C:\Users\sppaule\Desktop> .\Get-AudienceTargets.ps1 http://sppaule > audTargets.txt

Then, I open that file in Microsoft Excel, delimiting the columns on the ‘|’ character for easier reading.

I will note that I get a few “log4net” errors in the console window, but these aren’t included in the captured output and I’m not presently concerned with them because they’re probably coming from some of my other garbage. Also, you probably don’t want to execute this during your peak usage periods. Since it iterates through most of your content, it’s pretty intense and can take a long time to execute on farms with a lot of content.

Happy audience hunting!

Read Full Post »

As promised, here is the follow-up post from Mysteries of the “New” icon

Notice in this screen shot that we have two identical items:

Announcements list with two seemingly identical items. Only, one of the items has the "New!" icon.

Announcements list with two seemingly identical items. Only, one of the items has the “New” icon.

Whoa! How did this happen?

In the process of migrating a site from one web template to another (yes, another post to come, but this one may take a while since it’s pretty in-depth), I had created an export of a site and imported it using Import-SPWeb as such:

PS C:> Export-SPWeb http://sppaule/sites/test/oldSite -path 
   D:\Exports\old_Site -IncludeVersions 4 -NoFileCompression 
   -IncludeUserSecurity
PS C:> New-SPWeb http://sppaule/sites/test/newSite -Template "STS#1"
PS C:> Import-SPWeb http://sppaule/sites/test/newSite -Path 
   D:\Exports\old_site -NoFileCompression -IncludeUserSecurity

Now, the first time I did the import, there was no problem. Everything looked good. However, I didn’t stop there. I made a few tweaks to the export and re-issued the import command without first deleting the previous import. Instead of completely overwriting the previous import, a merge of the first import was done with the second import. Document libraries handle this without too much hassle, but the Ann0uncements list did not. The first item shown in the screen shot above was from the first import, and the second item was from the second import.

During the import process, SharePoint puts in the Created and Modified dates from the export data (i.e. the original dates). However, on import, the current date is put in for the fields with InternalName of Created_x0020_Date and Last_x0020_Modified. Since the two imports were done roughly a day apart, I ended up with a Created_x0020_Date field value for the two items that was also roughly a day apart and the New icon showed for only the more recent item.

I wouldn’t be surprised if the import merge was a result of the specific way I exported and imported or even may have had something to do with the small tweaks made to the export before re-import. Either way, I have learned a lesson: Always best to start with a clean slate when importing. As such, I should have done the following:

PS C:> Export-SPWeb http://sppaule/sites/test/oldSite -path 
   D:\Exports\old_Site -IncludeVersions 4 -NoFileCompression 
   -IncludeUserSecurity
PS C:> New-SPWeb http://sppaule/sites/test/newSite -Template "STS#1"
PS C:> Import-SPWeb http://sppaule/sites/test/newSite -Path 
   D:\Exports\old_site -NoFileCompression -IncludeUserSecurity
PS C:> Remove-SPWeb http://sppaule/sites/test/newSite
PS C:> New-SPWeb http://sppaule/sites/test/newSite -Template "STS#1"
PS C:> Import-SPWeb http://sppaule/sites/test/newSite -Path 
   D:\Exports\old_site -NoFileCompression -IncludeUserSecurity

Happy learning day!

Read Full Post »

It’s been far too long since I last blogged. To my followers: my apologies. There have been some great discoveries (particularly in the last few months), but none I have had time to write about, yet. Today, I ran into an intriguing situation that I felt needed to be shared that wouldn’t take long.

Take a look at this screen shot:

Announcements list with two seemingly identical items. Only, one of the items has the "New!" icon.

Announcements list with two seemingly identical items. Only, one of the items has the “New” icon.

Notice anything funny? (Okay, so I gave it away if you looked at the caption.) We’ve got two seemingly identical announcements in this list: both have the same title, creation date, and modification date. Only, one of them is showing the New icon and the other isn’t. I had to take a hard look at this!

Let’s disregard how I got to this for now and focus on the question at hand: Why would one item show the New icon and the other item not? They both show the same Created date and that is clearly not anywhere close the the timeframe for a new item (nearly a whole year earlier). Diving under the hood with PowerShell brought about the answer.

Let’s say $i1 and $i2 are, respectively, the SPListItem objects in PowerShell from the list shown above. My first clue came from inspecting the XML of $i2. There were clearly two dates given for the creation date, as such:

ows_Created='2012-02-29 15:17:19'
ows_Created_x0020_Date='1;#2013-02-20 17:46:57'

Again, let’s disregard how I came about with two different Created dates. It becomes clear that the New icon is going off the Created_x0020_Date field data. Furthering the inspection in PowerShell, we see the following:

PS C:> $f = $i1.Fields.GetFieldByInternalName("Created_x0020_Date")
PS C:> $i1[$f.id]
2013-02-19 16:44:52
PS C:> $i1["Created"]
Wednesday, February 29, 2012 3:17:19 PM

PS C:> $f = $i2.Fields.GetFieldByInternalName("Created_x0020_Date")
PS C:> $i2[$f.id]
2013-02-20 17:46:57
PS C:> $i2["Created"]

Wednesday, February 29, 2012 3:17:19 PM

Viola! Item 1 has a Created_x0020_Date that is outside of the range for a New icon, but Item 2 has a date within the range and thus shows the New icon.

The creation date shown in list views is the Created field where Title = "Created" and InternalName = "Created". While also having Title = "Created", the field used by the New icon is the one with InternalName = "Created_x0020_Date". You never see this later field (Created_x0020_Date) in the UI because it is hidden and readonly.

I’ll discuss how I came about this duplication in my next post, Duplicated list items.

P.S.–
If you need to see or change the duration your web application is set to for the New icon (i.e. how long the New icon will show), use the following PowerShell (copied from Deliveron Blog):

Get The Current Duration To Display The “New” Icon
$webApp = Get-SPWebApplication "http://webAppURL/"
$webApp.DaysToShowNewIndicator

Change The Duration To Display The “New” Icon
# Set to 1 Day
$webApp = Get-SPWebApplication "http://webAppURL/"
$webApp.DaysToShowNewIndicator = 1
$webApp.Update()

Prevent The “New” Icon From Displaying
# Essentially, just set the display duration to 0 days.
$webApp = Get-SPWebApplication "http://webAppURL/"
$webApp.DaysToShowNewIndicator = 0
$webApp.Update()

Read Full Post »

For quite some time, we’ve had difficulties editing user profiles using Central Admin’s Manage User Profiles page (ProfMngr.aspx). It will let us go to the Edit My Profile page (ProfAdminEdit.aspx) the first time, but every successive attempt to access the page results in an Access Denied–and it doesn’t matter what account (Admin, Farm, self, etc.) we use. Access Denied. Frustrating! “What do you mean, ‘Access Denied’?? I was just there!

The ULS logs don’t give many clues as to what’s going on, either. Futhermore, once your app pool for Central Admin recycles, you start over: one access allowed and then lockdown. Here’s what the ULS logs will show:

07/09/2012 10:03:21.07 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation Logging Correlation Data xmnv Medium Site=/ ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.13 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation Topology e5mc Medium WcfSendRequest: RemoteAddress: ‘http://sharepoint:32843/919746d29cfc419fb168abc82e2f7159/ProfileDBCacheService.svc’ Channel: ‘Microsoft.Office.Server.UserProfiles.IProfileDBCacheService’ Action: ‘http://Microsoft.Office.Server.UserProfiles/GetUserData’ MessageId: ‘urn:uuid:3b704fbf-2872-4140-a4a7-308261eb5b2a’ ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.15 w3wp.exe (0x1830) 0x294C SharePoint Foundation Topology e5mb Medium WcfReceiveRequest: LocalAddress: ‘http://sharepoint.local.int:32843/919746d29cfc419fb168abc82e2f7159/ProfileDBCacheService.svc’ Channel: ‘System.ServiceModel.Channels.ServiceChannel’ Action: ‘http://Microsoft.Office.Server.UserProfiles/GetUserData’ MessageId: ‘urn:uuid:3b704fbf-2872-4140-a4a7-308261eb5b2a’ ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.15 w3wp.exe (0x1830) 0x294C SharePoint Foundation Monitoring nasq Medium Entering monitored scope (ExecuteWcfServerOperation) ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.15 w3wp.exe (0x1830) 0x294C SharePoint Foundation Monitoring b4ly Medium Leaving Monitored Scope (ExecuteWcfServerOperation). Execution Time=0.44716929548675 ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.20 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation General 8e2s Medium Unknown SPRequest error occurred. More information: 0x80070005 ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.20 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation Monitoring b4ly Medium Leaving Monitored Scope (Request (GET:http://sharepoint:12345/_layouts/ProfAdminEdit.aspx?guid=ca5dda13-735d-afcd-8488-4d9c57fc721f&q=spsawyer&ConsoleView=Active&ProfileType=User&ApplicationID=919746d2%2D9cfc%1D419f%3Db168%2Dfbc82e2f7752)). Execution Time=128.538572630343 ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.20 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation Monitoring nasq Medium Entering monitored scope (Request (GET:http://sharepoint:12345/_layouts/AccessDenied.aspx?Source=http%3A%2F%2Fsharepoint%3A12345%2F%5Flayouts%2FProfAdminEdit%2Easpx%3Fguid%3Dca5dda13%2D735d%2Dafcd%2D8488%2D4d9c57fc721f%26q%3Dspsawyer%26ConsoleView%3DActive%26ProfileType%3DUser%26ApplicationID%3D919746d2%252D9cfc%252D419f%222Db168%252Dabc82e2f7159))

07/09/2012 10:03:21.20 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation Logging Correlation Data xmnv Medium Name=Request (GET:http://sharepoint:12345/_layouts/AccessDenied.aspx?Source=http%3A%2F%2Fsharepoint%3A12345%2F%5Flayouts%2FProfAdminEdit%2Easpx%3Fguid%3Dca5dda13%2D735d%2Dafcd%2D8488%2D4d9c57fc721f%26q%3Dspsawyer%26ConsoleView%3DActive%26ProfileType%3DUser%26ApplicationID%3D919746d2%252D9cfc%252D419f%222Db168%252Dabc82e2f7159) b24f736b-912e-471b-83f3-879e22eb228d

The key to figuring this out lies in that line about, “Unknown SPRequest error occurred. More information: 0x80070005”. That error deals with the portalsuperuseraccount and the portalsuperreaderaccount.

We had indeed set the portalsuperuseraccount and the portalsuperreaderaccount. Out of desire for best practice with least-privilege administration, we set the portalsuperuseraccount and the portalsuperreaderaccount to two different accounts. Unfortunately, the account we used as the portalsuperreaderaccount did not have access to the Edit My Profile page. The first time you access this page, it’s not yet cached. So, apparently, you don’t have problems. The second time, it is cached and, thus, [apparently] the portalsuperreaderaccount is used. (Could this be a security bug? Maybe.)

Solution: After changing the portalsuperreaderaccount for the web application in which CA is running to an account which does have access to edit user profiles, the problem disappeared. (If you decide to simply remove these properties, be sure to check out Tehnoon Raza’s post, “SharePoint 2010: How to Undo Portal Super Reader /Portal Super User Account Configuration for a Web Application“.)

Give it a try. My guess is that both the portalsuperuseraccount and the portalsuperreaderaccount need to have permissions, but I’ll leave that up to you to discover. 🙂

Read Full Post »

Older Posts »