The Very Best!

We provide consulting in a broad array of business and technology from architecture to design to deployment of global systems and we also provide legal expert services in eDiscovery, code discovery, patent infrigement, piracy and more! We also have established SICG DLDS s.a. - our counterpart in Costa Rica that specializes in water systems (http://www.crwatersolutions.com) - Contact me direct: david_sterling@sterling-consulting.com or call 704-873-8846.

Search This Blog

Loading...

Monday, August 25, 2014

SPWakeUp via PowerShell - My version

The SP Wakeup script works great - however, I added a loop through the central administration pages as well. I also added a command file that invokes it which enables the proper account (farm) to be used to start the command through the windows task scheduler.

Create the script/command file and put into a folder c:\SPWakeUp - use the Task Scheduler to invoke the script on a schedule and on system startup up (with a five minute delay) - be sure to set the tasks so that they will run when user is NOT logged in.

Script (SPWakeUp.ps1):
#
# Load the SharePoint PowerShell:
#
function Load-SharePoint-Powershell
{
     If ((Get-PsSnapin |?{$_.Name -eq "Microsoft.SharePoint.PowerShell"})-eq $null)
     {
              Write-Host -ForegroundColor White " - Loading SharePoint Powershell Snapin"
          Add-PsSnapin Microsoft.SharePoint.PowerShell -ErrorAction Stop
     }
}
#
# Wake up CA:
#
function SP-WakeUpCA()
{   
    # Get the CA Application:
    Write-Host -ForegroundColor White "Getting the CA Application URL..."
    $adminWebApp = Get-spwebapplication -includecentraladministration | where {$_.IsAdministrationWebApplication}
        $url = $adminWebApp.url
    Write-Host -ForegroundColor White "CA Application URL is " $url
    # Set up the URLs to hit:
    Write-Host -ForegroundColor White "Setup URLs"
    $urlHome = $url + "default.aspx" 
    $urlApps = $url + "applications.aspx"
    $urlSvcApps = $url + "_admin/ServiceApplications.aspx"
    $urlSvcsOnSvr = $url + "_admin/Server.aspx"
    $urlMonitor = $url + "monitoring.aspx"
    $urlHealth = $url + "Lists/HealthReports/AllItems.aspx"
    #
    # Hit them all:
    #
        Write-Host -ForegroundColor White "Setup Web Requests"
    $webRequestHome = [System.Net.HttpWebRequest]::Create($urlHome) 
    $webRequestHome.Timeout = 300000
    $webRequestHome.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    #
    $webRequestApps = [System.Net.HttpWebRequest]::Create($urlApps) 
    $webRequestApps.Timeout = 300000
    $webRequestApps.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    #
    $webRequestSvcApps = [System.Net.HttpWebRequest]::Create($urlSvcApps) 
    $webRequestSvcApps.Timeout = 300000
    $webRequestSvcApps.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    #
    $webRequestSvcsOnSvr = [System.Net.HttpWebRequest]::Create($urlSvcsOnSvr) 
    $webRequestSvcsOnSvr.Timeout = 300000
    $webRequestSvcsOnSvr.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    #
    $webRequestMonitor = [System.Net.HttpWebRequest]::Create($urlMonitor) 
    $webRequestMonitor.Timeout = 300000
    $webRequestMonitor.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    #
    $webRequestHealth = [System.Net.HttpWebRequest]::Create($urlHealth) 
    $webRequestHealth.Timeout = 300000
    $webRequestHealth.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    #
    # Hit them all:
    #
    try {
            Write-Host -ForegroundColor Green "Hitting Home Page - " $urlHome
        $resHome = $webRequestHome.GetResponse()
    }catch{
            Write-Host -ForegroundColor Red "ERROR Hitting Home Page"
        $error = $true
    }
    try {
            Write-Host -ForegroundColor Green "Hitting Applications Page - " $urlApps
        $resApps = $webRequestApps.GetResponse()
    }catch{
            Write-Host -ForegroundColor Red "ERROR Hitting Applications Page"
        $error = $true
    }
    try {
            Write-Host -ForegroundColor Green "Hitting Service Applications Page - " $urlSvcApps
        $resSvcApps = $webRequestSvcApps.GetResponse()
    }catch{
            Write-Host -ForegroundColor Red "ERROR Hitting Service Applications Page"
        $error = $true
    }
    try {
            Write-Host -ForegroundColor Green "Hitting Services On Server Page - " $urlSvcsOnSvr
        $resSvcsOnSvr = $webRequestSvcsOnSvr.GetResponse()
    }catch{
            Write-Host -ForegroundColor Red "ERROR Hitting Services on Server Page"
        $error = $true
    }
    try {
            Write-Host -ForegroundColor Green "Hitting Monitoring Page - " $urlMonitor
        $resMonitor = $webRequestMonitor.GetResponse()
    }catch{
            Write-Host -ForegroundColor Red "ERROR Hitting Monitoring Page"
        $error = $true
    }
    try {
            Write-Host -ForegroundColor Green "Hitting Health Analyzer List Page - " $urlHealth
        $resHealth = $webRequestHealth.GetResponse()
    }catch{
            Write-Host -ForegroundColor Red "ERROR Hitting Health Analyzer Page"
        $error = $true
    }
        Write-Host -ForegroundColor White "CA Wakeup process completed...."
}
#
# Get the web page passed:
#
function get-webpage([string]$url,[System.Net.NetworkCredential]$cred=$null)
{
    $error = $false
    $webRequest = [System.Net.HttpWebRequest]::Create($url) 
    $webRequest.Timeout = 300000
    if($cred -eq $null)
    {
        $webRequest.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    }
    try {
    $res = $webRequest.getresponse()
    }catch{
    $error = $true
    }
}
#
# Start the process:
#
Load-SharePoint-Powershell
#
# Wake up Central Administration:
#
$caURL = Get-SPWebApplication -includecentraladministration | where {$_.DisplayName -eq "SharePoint Central Administration v4"} | select Url
SP-WakeUpCA -url $caURL
#
# Now wake up any applications:
#
$webapplications = Get-SPWebApplication
$AllSites = Get-SPSite -limit all
$Array = @()
$i=0
foreach ($wa in $webapplications)
{
    foreach ($windowsauth in $wa.AlternateUrls)
    {
        $authenticationprovider= Get-SPAuthenticationProvider -webapplication $wa -zone $windowsauth.Zone
        If ($authenticationprovider.UseWindowsIntegratedAuthentication)
        {
            $accessableURL = $windowsauth.IncomingUrl
        }
    }
    if (!$AccessableURL) {$accessableURL = $wa.url -replace ".$"}
    foreach ($site in $AllSites)
    {
        if ($Site.Url -and $Site.Url+"/" -match $wa.url)
        {
            $subsites = Get-SPSite $Site.Url | Get-SPWeb -Limit All
            Foreach ($subsite in $subsites)
            {
                $i++
                Write-Progress -activity "Looking up all sites" -status "Please Wait..." -PercentComplete (($i / 500) * 100)
                $PlainWaUrl = $wa.Url -replace ".$"
                $WakeUpSite = $Subsite.Url.replace($PlainWaUrl, $accessableURL)
                $Array = $Array + $WakeUpSite
                #$html=get-webpage -url "$WakeUpSite" -cred $cred;
                if ($i -eq 500){$i=0}
            }
        }  
    }
    Remove-Variable accessableURL
}

$i=0
Foreach ($Website in $Array)
{
    $i++
    Write-Progress -activity "Waking up sites" -status "Waking: $Website" -PercentComplete (($i / $Array.Count) * 100)
    $html=get-webpage -url "$Website" -cred $cred;
}


Now for the Command file (SPWakeUp.cmd) which you use for the Task Scheduler (all on one line):

c:\Windows\System32\WindowsPowershell\v1.0\Powershell.exe -ExecutionPolicy Bypass -File c:\SPWakeup\SPWakeup.ps1

Have fun!

Wednesday, June 11, 2014

SharePoint 2013 Site Fails to render on create, you receive 500 Internal Error or you see Event ID 8305

So you create a brand new Web Application then create a Site Collection (template unimportant). Instead of the site rendering, you get a blank page. Or if lucky, you see a 500 Internal Error message.

As usual, this is a security issue with SharePoint and since environments vary quite a bit, it can be a tough one to track down. Generally this is a problem with the Application Pool Identity (the account used for the application pool for the web application). On each of the servers, follow these steps:

  1. Verify the account has local permissions (on the server(s), open Administrative Tools > Local Security Policy then expand Local Policies then click on User Rights Assignment) - this account REQUIRES "Log on as a service" and "Impersonate a client after authentication"
  2. Verify the account is a member of the WSS_WPG group
  3. Verify on the local server(s) that the Application Pool has access to SQL Server



Friday, May 2, 2014

SharePoint 2013 Claims to Windows Token Service not starting after reboot

CLAIMS TO WINDOWS TOKEN SERVICE NOT STARTING AFTER REBOOT

The Claims to Windows Token Service should be running all all servers in the farm. If on a restart of a server, the service won’t start or is stuck on starting, the issue may be with the Cryptographic Services Service. This is a timing issue in which that service hasn’t started before the claims service has. The solution is to add a dependency to the service definition so that the CS service will start before claims:

1) Open a Command Prompt (or PowerShell) using Run as administrator
2) Type in the command:

sc config c2wts depend=CryptSvc

3) Hit Enter then close the command prompt
4) Open the Services console (Start > Run > services.msc or Start > Administrative Tools > Services)
5) Find the Claims to Windows Token Service in the list then right click on it and select Properties.
6) On the Properties pop-up, click the Dependencies tab and verify that the Cryptographic Services is listed and click OK to close

SharePoint 2013 - Event ID 6398

Event ID 6398

Error on Search Servers indicating:

The Execute method of job definition Microsoft.SharePoint.Diagnostics.S PDiagnosticsMetricsProvider threw an exception


This means that the permissions are inadequate on the location of the SharePoint Logs – verify that the WSS_WPG and WSS_ADMIN_WPG local groups have full permissions to the drive/folders in use. 

SP13: Security Token Service is not available

As may be reported by the Health Analyzer or as a message in the System Event Application Log:

The SharePoint Health Analyzer detected a condition requiring your attention.  The Security Token Service is not available.
The Security Token Service is not issuing tokens. The service could be malfunctioning or in a bad state.
Administrator should try to restart the Security Token Service on the boxes where it is not issuing tokens. If problem persists, further troubleshooting may be available in the KB article. For more information about this rule, see "http://go.microsoft.com/fwlink/?LinkID=160531".

This indicates that the SharePoint Web Services Root application pool is stopped. Open Internet Information Services (IIS) Manager, expand server then click on Application Pools – right click on the SharePoint Web Services Root and select Start:



Other possible causes:
The Security Token Service hasn’t been provisioned
1.       Login to a SharePoint server as the Farm Account
2.       Open the SharePoint 2013 Management shell using Run as administrator
3.       Enter in the following commands:
$sts = Get-SPServiceApplication | ?{$_ -match "Security"}
$sts.Status
$sts.Provision()

Incorrect Authentication Settings in IIS
1.       Open Internet Information Services (IIS) Manager
2.       Expand the Sites folder
3.       Expand the SharePoint Web Services folder
4.       Click on the SecurityTokenServiceApplication to select it
5.       In the Features pane in the IIS section, double click on Authentication
6.       Right click on Forms Authentication and select Disable (for SharePoint,only Windows and Anonymous access should be enabled for tokens and the claims service to work correctly)

Bad data in the Web.config File
Check the web.config file in the site for errors (use Windiff to compare to a working web.config) and/or remove any manual changes that may have been made.

Saturday, February 22, 2014

Installing Disk Cleanup without the Desktop Experience

Like many folks have found, the Windows Disk Cleanup utility is very handy indeed - particularly for those that have upgraded an OS. There are a lot of files left over that it can be difficult to remove. While a great utility, Microsoft has opted to install it as part of the Desktop Experience feature. This means that a whole boatload of stuff is installed that isn't needed on a server (handwriting, media tools, etc.). 

In the past, I like many of you have just accepted this - taking the bloatware for the good of the utility.

But no more!!

It turns out that the Disk Cleanup feature can be installed manually without the need for the Desktop Experience. To do this however requires that it be installed on a server to retrieve the necessary files. 

First, it is necessary to install the Desktop Experience on a server with the same OS as the target. Once installed, there are two files that must be retrieved (location depends on the OS) as follows:

Get the EXE file from here:
  • Windows Server 2008 R2 - 64-bit:
    • C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr_31bf3856ad364e35_6.1.7600.16385_none_c9392808773cd7da\cleanmgr.exe
  • Windows 2012 64-bit:
    • C:\Windows\WinSxS\amd64_microsoft-windows-cleanmgr_31bf3856ad364e35_6.2.9200.16384_none_c60dddc5e750072a\cleanmgr.exe



Get the MUI from here:
  • Windows Server 2008 R2 - 64-bit:
    • C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr.resources_31bf3856ad364e35_6.1.7600.16385_en-us_b9cb6194b257cc63\cleanmgr.exe.mui
  • Windows 2012 64-bit:
    • C:\Windows\WinSxS\amd64_microsoft-windows-cleanmgr.resources_31bf3856ad364e35_6.2.9200.16384_en-us_b6a01752226afbb3\cleanmgr.exe.mui



Copy these files to a server to the following locations:
  • Cleanmgr.exe should go in %systemroot%\System32
  • Cleanmgr.exe.mui should go in %systemroot%\System32\en-US


Where %systemroot% is typically c:\windows.


If desired, create a shortcut to %windir%\System32\Cleanmgr.exe and name it Disk Cleanup.

Problem Solved!!!

If you want to trust a download, here it is:


Tuesday, January 14, 2014

Slipstreaming SharePoint 2013 and SharePoint Cumulative Updates

As was true with SharePoint 2010, Microsoft is releasing Cumulative Updates (CU's) for 2013. A new CU is generally released about every 3 months. As has been confirmed, ONLY the latest CU needs to be applied EXCEPT for 2013. For 2013, there is a mandatory update for March 2013 (which includes February 13's updates). The latest CU cannot be installed without the March 2013 applied first.

As for the CU's themselves, be sure to check for any issues folks have encountered and follow a normal process of testing on a non-production farm first. As an example, the latest CU (December 2013) has a known side effect in that it breaks the Performance Point dashboard designer - so if you are using Performance Point, don't install that CU (install October instead).

The entire list can be found here: http://technet.microsoft.com/en-us/sharepoint/jj891062.aspx

At any rate, it's not a lot of fun to have to incorporate the CU's on multiple systems - particularly when there are more than one. As well, Microsoft is not very clear about what to apply when - as in do you do Foundation, then Server or just Server and do you run SharePoint Configuration update after or not?

To clear the air on at least 2013, it now appears that CU's should only be applied based on the product you are running. That is, if you are running Server, ONLY apply the Server update - if running Foundation, ONLY Foundation. This can save you some time as like many of  you, I have in the past implemented both just to be sure (and Microsoft is very vague on this).

As for running PSCONFIG or SharePoint Configuration after each, the answer is YES - do it every time.

If you choose to run each of the updates separately, be aware that the updates DO NOT ALWAYS upgrade everything. Case in point: When applying the March 2013 update, it does not update the Business Connectivity Server (BCS) - after the update is done, a message will appear in the Health Analyzer that the BCS/BDC Database is running in compatibility mode. To correct this, use the SharePoint 2013 Management Shell (i.e. PowerShell) and provision the database as follows:

(Get-SPDatabase | ?{$_.type -eq "Microsoft.SharePoint.BusinessData.SharedService.BdcServiceDatabase"}).Provision()

As for "Slipstreaming", the process works the same way as it did in 2010.

NOTE: At the time of this writing, I have confirmed that the March 2013 CU is the only update that can be used in the slipstream process - the December 2013 CU must be applied manually after.

There are a few steps involved to do this.

1) Download all of the cumulative updates from the site for your product but be SURE to keep them in separate folders. When 'extracted', Microsoft uses cute names (ubersts for example) that are either because the update is coming from Germany or someone bought a VW and likes the term and includes the KB numbers so it's impossible to know which comes from which date.

2) For each the CU's, extract them to a folder - so for example, create a folder called March13CU. Copy the update (an .EXE file) to that folder - if the update (like August) comes in the form of a self-extracting zip, use that to extract the EXE (and in some cases, .CAB files) into that folder.

3) Use PowerShell or the command prompt, set default to the folder (i.e. March13CU) then breakout the CU EXE into individual files using the extract method - to extract them to the same folder, the command would be:

<CU EXE Name> /extract:<folder to extract to>

So if the downloaded CU was called March13ServerCU.exe (or you wisely renamed it as so) and wanted to extract it to the folder March13CU (the same folder where the EXE is), the command would be:

March13ServerCU.exe /extract:.\

Alternately, to create a sub-folder, the command would be:

March13ServerCU.exe /extract:.\Mar13SrvCU

If you wanted to use a different drive/folder, it would be:

March13ServerCU.exe /extract:D:\Mar13SrvCU

4) Copy the SharePoint installation into a folder on the server.

5) Run the Prerequisite installer either using the Splash screen running Setup.cmd or using the prerequisiteinsaller.exe - either way be SURE TO right click and choose Run as administrator (do this for EVERYTHING relating to SP13).

6) After the Prerequisites are installed, there are additional patches that must be run:

    *   KB2554876 - The SharePoint parsing process crashes in Windows Server 2008 R2.  (http://support.microsoft.com/kb/2554876)
    *   KB2708075 - IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes.  (http://support.microsoft.com/kb/2708075)
    *   KB2472264 - You can't customize some TCP configurations by using the netsh command in Windows Server 2008 R2.  (http://support.microsoft.com/kb/2472264)
    *   KB2567680 - Vulnerability in Windows Client/Server Run-time subsystem could allow elevation of privilege.  (http://download.microsoft.com/download/C/D/A/CDAF5DD8-3B9A-4F8D-A48F-BEFE53C5B249/Windows6.1-KB2567680-x64.msu)
    *   KB2759112 - Hotfix for the .NET Framework 4.5 that resolves an ASP.NET race condition issue in Windows Server 2008 R2. (http://support.microsoft.com/kb/2759112) (download:  http://go.microsoft.com/fwlink/p/?LinkId=267536)

    *   KB2765317 - Hotfix for the .NET Framework 4.5 that resolves an ASP.NET race condition issue in Windows Server 2012. (http://support.microsoft.com/kb/2765317) (download:  http://go.microsoft.com/fwlink/p/?LinkID=268725)

While running these updates, if you receive an error or message saying "Update not applicable", that's fine. The key one here is KB2759112 - you CANNOT run a slipstream installation unless this has been applied.

7) If you are running a VM, snapshot it at this time (this gives you a fallback if the installation doesn't work).

8) Prepare the slipstream installation by copying the extracted CU files into the installation folder called 'updates'. Be sure to copy them in order by date released, March, August, etc.

9) Run the SharePoint setup (on ONE SERVER ONLY) - the first step of this only installs the binaries. At the end, if it says "Compete" the update took - if it shows "Some updates were not applied" you are hosed and you need to start over or install the CU's manually. When complete, you can verify the version installed by going to the hive, c:\Program files\common files\microsoft shared\web server extensions\15\isapi then right clicking on Microsoft.SharePoint.dll and selecting properties then clicking the Details tab. You can validate the number either from the Microsoft site or Steve Chen's blog post:
http://blogs.technet.com/b/steve_chen/archive/2013/03/26/3561010.aspx

If the first server went OK, copy the same installation folder to other servers to install there.

10) As a first time installation, running the SharePoint 2013 Configuration Wizard will apply the updates so PSConfig (or PSConfigUI) not needed.