Microsoft cloud engineer - SharePoint, Office 365, Azure, DotNet, Angular, JavaScript.
Microsoft cloud engineer - SharePoint, Office 365, Azure, DotNet, Angular, JavaScript.

SharePoint 2010

How to point to a custom 404 error Web page

Recently I was working on a custom 404 page with JavaScript logic for retiring an old SharePoint farm.   Replacing the “oldportal” DNS name with “newportal” helped avoid any end user 404 message by automatically handling all redirects.   Microsoft has a great KB article with implementation steps.   However, I had two important changes and wanted to blog about it in case this might help others.

  1. Custom JavaScript redirect logic.   A simple replace statement helps change “oldportal” to “newportal” and seamlessly transition user traffic to the new system.
  2. PowerShell instead of Visual Studio EXE.   Not everyone has Visual Studio or the developer skills needed for compiling a command line EXE.   PowerShell is a simple text command you can run on MOSS2007/SP2010/SP2013 because it references the “Microsoft.SharePoint” assembly and works on older SharePoint server versions.




PowerShell Code – apply web application setting

$webapp = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup("http://oldportal")
$webapp.FileNotFoundPage = "Custom404.htm"


HTML Code – Custom404.htm

<!-- _localBinding -->
<!-- _lcid="1033" _version="" -->
<meta HTTP-EQUIV="Content-Type" content="text/html; charset=utf-8" />
<meta HTTP-EQUIV="Expires" content="0" />
	<meta http-equiv="refresh" content="0; url=/_layouts/spsredirect.aspx?noscript=1" />
<script language='javascript' src="_/layouts/lO33/init.js"></script>
<script language='javascript' src="_/layouts/1033/core.js"></script>
<script language='javascript'>
//requestedUrl = escapeProperly(window.location.href);
//STSNavigate(”/layouts/.?oldUrl=” + requestedUrl);
var dest = window.location.href.replace("oldportal","newportal") .toString();
window.location.href = dest;

Launch IE as multiple users for testing

When testing role based security, it can be helpful to right click IE and “Run as different user.”   The below PowerShell script automates this process to make it easier to launch multiple IE windows for testing.   Keeping a copy on Windows 7/8 workstations can help users jump into testing easily and with fewer password typo lockouts.    If you find this helpful, please leave a comment. 



# Launch multiple IE windows as different test user accounts.  Great for testing role based security systems.
# Updated line 3 with user name, line 6 with Active Directory domain, and line 9 with SharePoint URL.
$users = ('sptest1','sptest2','sptest3','sptest4')
foreach ($u in $users) {
	Write-Host $u
	$username = ('domain\' + $u)
	$password = 'pass@word1'
	$cred = New-Object System.Management.Automation.PSCredential -ArgumentList @($username,(ConvertTo-SecureString -String $password -AsPlainText -Force))
	Start-Process "c:\Program Files\Internet Explorer\iexplore.exe" -LoadUserProfile -Credential $cred -ArgumentList "http://sharepointUrlHere"


Here is a screenshot of the script in action.


PowerShell – Notify all site users for outage / maintenance

The below PowerShell can be used to email all users of all site collections on your system.   I find this helpful when planning maintenance outages to alert users of the down time, impact, and changes being performed.


Get-SPSite -Limit All |% {$url = $_.url;$_.RootWeb.SiteUsers | select UserLogin, DisplayName, Email, @{Name="SiteUrl";Expression={$url}}} | Export-Csv SiteUsers.csv



View disabled Health Check rules – PowerShell one liner

Scripting this was harder than I thought it should be, so I wanted to share this crazy long PowerShell one liner.  If anybody knows of a shorter way, please leave a comment or Tweet me.   First, we get the web applications including a special switch to get Central Admin (which is normally skipped for safety).   Then we get the site collections, but since help collection has one we need to filter those out.  Then we grab the Health Analyzer Rules Definitions list.  Finally, we can filter for disabled items and display as a table.

When working on a new farm that someone else installed.  Or heck, even one I installed but just can’t remember how.  This is a good way to confirm your assumptions about any red or yellow Health warnings you see (or don’t see because they’re suppressed)


(Get-SPWebApplication -IncludeCentralAdministration |? {$_.IsAdministrationWebApplication -eq $true} |
Get-SPSite |? {$_.Url -notlike '*help'}).Rootweb.Lists["Health Analyzer Rule Definitions"].Items |?
{$_["HealthRuleCheckEnabled"] -eq $false} | select Title,ID | ft -AutoSize


I would also recommend creating a new filtered view in the Central Admin GUI for an easy way to quickly view these going forward.  There are legitimate times when a rule should be disabled, that’s why we have the checkbox.  However, it pays to know what the current settings are and not forget those hidden items.

Once all of the health rules are the way you like, run a quick SPTimerJob refresh to see the outcomes of those rules. 



Get-SPTimerJob |? {$ -like '*-health-*'} | Start-SPTimerJob



© Copyright 2016
@ SPJeff

Return to Top ▲Return to Top ▲