*** UPDATE 12/31/2017: This Project Was Migrated From CodePlex to Github ***
Releases:
- Version 2: (Stable) [ Nov 28 2011]
- Version 1 (Stable) [ Mar 28 2011]
Showing posts with label SharePoint. Show all posts
Showing posts with label SharePoint. Show all posts
SharePoint Event Receiver Manager (2007 & 2010)
Releases:
Stuck in the Past! SharePoint Alerts Pointing to An Old URL After Migration?
I've run into this personally a couple of times and never really documented my own solution so that I had it for myself to reuse. If the URL for your SharePoint Farm ever changes you're more than likely to start hearing from your users that the alert subscription emails they get still point to the old Farm URL. I've encountered this on SP 2007 and SP 2010 Farms. As it turns out, each Alert Subscription contains a hard coded server root URL which is used when the alert email is generated to construct links. I wrote, and you'll see several other examples out there, the PowerShell script below to loop through all Web Applications of the server and perform an update on all Alert Subscriptions. I like my scripts that need to be run on all sites to run through my whole farm rather than one site at a time. This script works on both SP 2007 and SP2010. This script will Skip the Central Admin Web Application and Your SSP and MySite Sites.
$oldrooturl = "https://<url>"
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")> $null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Portal")> $null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Security")> $null
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local;
$services = @($farm.Services | where -FilterScript {$_.GetType() -eq [Microsoft.SharePoint.Administration.SPWebService]})
foreach ($service in $services)
{
foreach($app in $service.WebApplications)
{
$sites = $app.Sites
if ($app.DisplayName.Contains('Central Administration'))
{
continue
}
foreach ($site in $sites)
{
if (!$site.ServerRelativeUrl.Contains("ssp/") -and !$site.ServerRelativeUrl.Contains("MySite"))
{
$rooturl = $site.Url.Replace($site.ServerRelativeUrl, '')
foreach ($web in $site.AllWebs)
{
$updated = 0
$alerts = $web.alerts
Write-Host "Number of Alerts in: "$web.url ":" $alerts.count
if ($alerts.count -ne 0)
{
foreach ($alert in $alerts)
{
$alert.Status = [Microsoft.SharePoint.SPAlertStatus]::Off
$alert.Update()
if ($alert.Properties -ne $null)
{
$changed = $FALSE
$siteUrl = $alert.Properties["siteurl"]
if ($siteUrl -ne $null -and $siteUrl.Contains($oldrooturl))
{
$alert.Properties["siteurl"] = $siteUrl.Replace($oldrooturl, $rooturl)
$changed = $TRUE
}
$mobileUrl = $alert.Properties["mobileurl"]
if ($mobileUrl -ne $null -and $mobileUrl.Contains($oldrooturl))
{
$alert.Properties["mobileurl"] = $mobileUrl.Replace($oldrooturl, $rooturl)
$changed = $TRUE
}
if ($changed)
{
$updated++
write-host "Alert updated: " $alert.Title "For User: " $alert.User
}
}
$alert.Status = [Microsoft.SharePoint.SPAlertStatus]::On
$alert.Update()
}
Write-Host "Number of alerts updated: " $updated
}
}
}
$site.Dispose()
}
}
}
SharePoint Closed WebParts Slowing You Down? Migrating from SharePoint 2007 to 2010 and Can't Find an Easy Way to Resolve (preupgradecheck) Findings? PowerShell's Got Your Back!
Performance is a concern of every system administrator, unless you're an Information Assurance Kind of guy and then you'd probably just assume see the server switched off (just a bit of a nudge), and if SharePoint is your poison watch out for Closed WebParts throughout your site. Closed WebParts are still attached to your page, are temporarily hidden but they do load when your page loads and if there are a number of them or any with Fatal Errors you're unecessarily impacting page load times and probably filling your logs with errors that you're having a difficult time tracking down. Worse yet if you plan a migration from SharePoint 2007 to 2010 and run the preupgradecheck STSADM command you'll find yourself with a nice list of things that could be problems during an upgrade and no clear path to resolve things in that list.
<!--more-->
The handy PowerShell script below can help with both. It will iterate through all of the web applications on your server and the pages at the root of each site (it doesn't look at pages in libraries which could also be an issue) and deletes closed WebParts as well as reporting WebParts that themselves are reporting a Fatal Error. Can make site cleanup much faster and perk up you site performance, especially if you have an older SharePoint Farm that's been through the ringer.
<!--more-->
The handy PowerShell script below can help with both. It will iterate through all of the web applications on your server and the pages at the root of each site (it doesn't look at pages in libraries which could also be an issue) and deletes closed WebParts as well as reporting WebParts that themselves are reporting a Fatal Error. Can make site cleanup much faster and perk up you site performance, especially if you have an older SharePoint Farm that's been through the ringer.
#Load assemblies
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")> $null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Portal")> $null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Security")> $null
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local;
$services = @($farm.Services | where -FilterScript {$_.GetType() -eq [Microsoft.SharePoint.Administration.SPWebService]})
foreach ($service in $services)
{
foreach($app in $service.WebApplications)
{
$sites = $app.Sites
foreach ($site in $sites)
{
if (!$site.ServerRelativeUrl.Contains("ssp/"))
{
foreach ($currentWeb in $site.AllWebs)
{
$pages = $currentWeb.Files | Where-Object {$_.Name -match ".aspx"}
Write-Host "Analyzing Web $($currentWeb.Url)."
foreach($currentPage in $pages)
{
Write-Host "Analyzing Page $($currentPage.ServerRelativeUrl)."
if ($currentPage.CheckedOutByUser -ne $NULL)
{
$currentPage.CheckIn("Administratively Checked-In");
}
$url = $currentPage.ServerRelativeUrl;
if ($url -eq $NULL)
{
continue
}
$webPartManager = $currentWeb.GetLimitedWebPartManager($url, [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)
$closedWebparts = New-Object System.Collections.ArrayList
$badWebparts = New-Object System.Collections.ArrayList
foreach($webpart in $webPartManager.WebParts)
{
if($webpart.IsClosed)
{
$closedWebparts.add($webpart);
}
elseif ($webpart.FatalError)
{
$badWebparts.add($webPart)
}
else
{
$webPart.AllowClose = $FALSE;
$webPart.AllowZoneChange = $TRUE;
}
}
foreach($webpart in $closedWebparts)
{
Write-Host "Deleting closed webpart $($webpart.Title) on page $($currentPage.ServerRelativeUrl)."
$webPartManager.DeleteWebPart($webpart);
}
foreach($webpart in $badWebparts)
{
Write-Host "$($webpart.ID) on $($currentPage.ServerRelativeUrl) is reporting $($webpart.ImportErrorMessage) "
#$webPartManager.DeleteWebPart($webpart);
}
}
$currentWeb.Dispose()
}
}
$site.Dispose()
}
}
}
One or more field types are not installed properly. Go to List settings page to delete these fields. After Upgrading A SharePoint Site Collection From 2007 to 2010
SharePoint Is a fickle beast and moving from SharePoint 2007 to SharePoint 2010 has the potential to produce the expected problems. I recently moved a SharePoint 2007 site collection to SharePoint 2010 by importing the 2007 database on the 2010 farm. I was stumped for a bit on an error that was unspecific and didn't really tell me what the problem was "One or more field types are not installed properly. Go to List settings page to delete these fields." This error was impacting the Pages library and popped up when any page in that library was loaded. No reference to a specific field type in the actual error displayed when I had custom errors disabled and no reference to the specific field in the ULS logs.
Subscribe to:
Posts (Atom)