Joel's SharePoint Architect Blog

SharePoint 2013 Training, Architecture, Administration and Development

Subscribe Subscribe  View Joel Jeffery's profile on LinkedIn
joelblogs.co.uk | joelj.co.uk | joeljeffery.co.uk | jfdiphoenix.co.uk

Posts Tagged ‘SharePoint Administration’

Ever lost your Farm password?

Farm Password Recovery in SharePoint 2010

The other day I was asked by a customer, “hey, would you happen to have a copy of our Farm password anywhere?”

No, I didn’t. And it would kind of be bad if I did!

However, I could recover SPFarm passwords and recover other Application Pool account passwords for them, once Remote Desktopped in to one of the SharePoint servers.

If you want to recover the Farm password, you need to sign in with a Local Administrator account on a server running Central Admin.

If you want to recover one of the Web Application or Service Application passwords, then you need to log in to one of those servers instead.

IIS 7.x runs Central Admin in the context of an Application Pool running under the Farm Account credentials. Similarly, Web Applications and Service Applications run in App Pools with their own credentials.

To recover any of these, start up an Administrative command prompt or PowerShell window, and IIS Manager 7.x.

In IIS Manager, you need to find out the name of the Application Pool.

IIS Showing Application Pools

For Central Admin, that would be:

SharePoint Central Administration v4

But we can also uncover the passwords for other Application Pools, e.g.:

SharePoint – 80

SharePoint Web Applications

e4b4b94050634ad2863ad7d7d17c3a17

Next, at the command prompt (or PowerShell) you can use the IIS appcmd.exe to request the Password field from the ProcessModel section of the applicationHost.config file. For example, in PowerShell (on ONE LINE!):

&$env:windir\\system32\\inetsrv\\appcmd.exe list apppool 
 "SharePoint Central Administration v4" /text:ProcessModel.Password

An example run is shown below:

Extracting Passwords for Application Pools in IIS

Hope this helps someone!

Technorati Tags: PowerShell, SharePoint, SharePoint Administration

SharePoint Documentation Kit (SPDocKit)

I need to tell you about something fantastic.

SharePoint Documentation Kit – SPDocKit Review

I’ve been using SPDocKit from Acceleratio for about 6 months now, on and off. One of the services we offer at JFDI Phoenix is our SharePoint 2010 Farm Health Check, and this involves a lot of boring navigation through Central Admin and some gnarly PowerShell to gather farm insight. Collecting settings information by hand is tough and time consuming.

The value-add for customers comes from what I can deduce from their configuration – what problems they’ll see; whether their platform will scale; whether it will be secure enough.

SPDocKit helps me gather the vast majority of the information I need, and formats it into a very detailed, very useful report in Word format.

Here’s just a snippet from the table of contents:

SPDocKit Table of Contents

It goes on to produce a detailed inventory of each server in the farm:

Farm Overview

It even builds a Visio-style diagram showing the farm topology. OK, I know it looks daft when I run it on a one-server farm, but it is vastly more impressive on a multi-server farm!

Farm Topology

It also identifies and lists:

  • Services on server, per server
  • Site topology (site collections per web application)
  • Web applications
  • Self-service site creation settings
  • Alternate access mappings
  • IIS settings
  • Site collection usage
  • Quota templates
  • Service applications
  • Detailed settings for each application
  • Databases used
  • Permissions
  • Associations to web applications and proxy groups
  • Content databases, usage and quotas
  • System settings, including email and SMS settings
  • Features and solutions
  • Sandbox configuration
  • Monitoring and reporting
  • Security
  • Administrators
  • Managed accounts
  • Service accounts
  • Products and versions
  • Scheduled tasks
  • Server information
  • Hardware / cores
  • Installed programs and hotfixes
  • Drives and free space

If this wasn’t enough, it also lets you record all this information and monitor changes over time.

More Features!

And there’s more! The SPDocKit application itself has a pretty useful UI. You can browse the web application and site structure without needing to generate documentation:

Site Explorer

It also lets you walk the permissions of your sites. Very useful if you’ve been breaking inheritance and you want to know who has access to what. Having said that, SharePoint’s built-in “Check Effective Permissions” button is still invaluable to debugging permissions problems.

Permssions Explorer

There’s also a Detailed Permissions report, but this is still a very interactive tool:

Detailed Permissions

There’s even best practices analysis built in:

Best Practices

Although obviously not exhaustive, it does give a very good start for a more detailed analysis of a farm.

There’s also a Scheduled Tasks viewer:

Scheduled Tasks

Conclusion

Whilst SPDocKit is not magic, it certainly saves me a great deal of time on SharePoint farm health checks. The licensing is pretty cool also. You can either buy it for an individual farm, of have a yearly subscription as a consultant. If you’re using the latter, the setup exe lets you run it on a server without leaving it installed afterwards.

Technorati Tags: SharePoint 2010, SharePoint Administration, SharePoint Architecture

A while ago, a student of mine asked if it was possible to use the taxonomic alternative labels from the Managed Metadata Service as thesaurus items in SharePoint Server Search.

There’s no built-in way to do this, but it is possible to generate the required Xml with a little PowerShell.

The Concept

The Term Store contains Term Group, which content Term Sets, which in turn contain nested Terms. Each Term can have (optional) synonyms called Labels.

If we find all the Terms with Labels, we can write them out in the correct format as a chunk of Xml, and pipe it into a thesaurus file.

Thesaurus files for SharePoint Server Search are kept under the file path:

%ProgramFiles%\Microsoft Office Servers\14.0\Data\Office Server\Applications\GUID-query-0\Config

A sample thesaurus file is shown below:

<XML ID="Microsoft Search Thesaurus">
    <thesaurus xmlns="x-schema:tsSchema.xml">
        <diacritics_sensitive>0</diacritics_sensitive>
        <expansion>
            <sub>Internet Explorer</sub>
            <sub>IE</sub>
            <sub>IE8</sub>
        </expansion>
        <replacement>
            <pat>NT5</pat>
            <pat>W2K</pat>
            <sub>Windows 2000</sub>
        </replacement>
    </thesaurus>
</XML>

You can see the rationale for how this file works on and how to manage thesaurus files at TechNet.

The Script

The script below shows the principle. It iterates over the Terms in each Term Store and finds their Labels. Where the Label is not the same as the name of the Term itself, it represents a synonym and we add it to the Xml.

function Extract-SPThesaurusFromTermLabels
{
  param([string] $webUrl);
  $ts = Get-SPTaxonomySession -Site $webUrl;
  Write-Output "<XML ID='Microsoft Search Thesaurus'>"; 
  Write-Output "<thesaurus xmlns='x-schema:tsSchema.xml'>"; 
  $ts.TermStores | 
  % { $_.Groups | 
    % { $_.TermSets | 
      % { $_.Terms | 
        % { $_.Labels | 
          ? {$_.Term.Name -ne $_.Value} |
          % { 
            Write-Output ("<expansion><sub>" + $_.Term.Name + 
              "</sub><sub>" + $_.Value + "</sub><expansion>");
          } 
        } 
      } 
    } 
  }; 
  Write-Output "</thesaurus>"; 
  Write-Output "</XML>";
}

You can then pipe the output of this command to an Xml file, and optionally use this in the place of your existing Thesaurus file with something like this:

Extract-SPThesaurusFromTermLabels http://sharepoint > tsLANG.xml

As always, please back up your original Thesaurus files and check the output of this before you use it! Smile

Technorati Tags: PowerShell, Search, SharePoint, SharePoint 2010, SharePoint Administration, SharePoint Administrator

The purpose of STSADM’s “copyappbincontent” command is:

stsadm –o copyappbincontent

Copies Web application–specific files, such as page resource (*.resx) files from their respective locations in the 12\CONFIG folder to the correct location in each Web application on the computer.

According to TechNet, there is no equivalent PowerShell cmd-let http://technet.microsoft.com/en-us/library/ff621081.aspxt:

No PowerShell Equivalent to stsadm -o copyappbincontent

However, there is a PowerShell cmd-let called Install-SPApplicationContent:

Install-SPApplicationContent

Copies shared application data to existing Web application folders.

Now that sounds pretty similar.

I’ve tried this out – making a custom layouts.sitemap.xml file, and invoking Install-SPApplicationContent. It copies/merges the sitemap into the correct place under inetpub\wwwroot\wss\VirtualDirectories\*\_app_bin.

So, how dissimilar are they? I’ve heard it said that the PowerShell version won’t apply your changes to the whole farm, only the current server. But surely, that’s what stsadm does too?

Let’s use the rather fantastic open-source ILSpy replacement for Reflector to reflect over the code,

STSADM’s copyappbincontent decompiled

// Microsoft.SharePoint.StsAdmin.SPCopyAppBinContent
public override void Run(StringDictionary keyValues)
{
    SPServiceInstance sPServiceInstance = SPWebServiceInstance.LocalContent;
    if (sPServiceInstance != null && sPServiceInstance.Status == SPObjectStatus.Online)
    {
        SPWebService contentService = SPWebService.ContentService;
        contentService.ApplyApplicationContentToLocalServer();
    }
    sPServiceInstance = SPWebServiceInstance.LocalAdministration;
    if (sPServiceInstance != null && sPServiceInstance.Status == SPObjectStatus.Online)
    {
        SPWebService administrationService = SPWebService.AdministrationService;
        administrationService.ApplyApplicationContentToLocalServer();
    }
}

Microsoft.SharePoint.PowerShell’s Install-SPApplicationContent decompiled

if (sPWebServiceInstance.Status == SPObjectStatus.Online)
{
  SPWebService administrationService = SPWebService.AdministrationService;
  ServiceHelper.TryToControlService("W3SVC", false, out flag, out flag2);
  administrationService.ApplyApplicationContentToLocalServer();
}
if (null != SPWebServiceInstance.LocalContent)
{
  if (SPWebServiceInstance.LocalContent.Status == SPObjectStatus.Online)
  {
    ServiceHelper.TryToControlService("W3SVC", false, out flag3, out flag4);
    SPWebService contentService = SPWebService.ContentService;
    contentService.ApplyApplicationContentToLocalServer();
  }
}

Conclusion

So, there you have it. Like two completely dissimilar things… in a pod.

To be clear: you need to invoke either of these methods on each server in your farm to deploy content from the 14 hive to the IIS virtual directories.

Or have I missed something?

Technorati Tags: PowerShell, SharePoint, SharePoint 2010, SharePoint Administration, SharePoint Development

SharePoint 2010 Locale Stapler / Master Locale

I’ve just put up another project on CodePlex. As usual, you can download the full project and source code for SharePoint 2010 Locale Stapler.

Why?

SharePoint doesn’t let you set a master locale per web application. SharePoint 2010 Publishing Features lets you specify that all sub sites inherit the locale settings from the parent… But this is sadly lacking.

How?

My project gives you a SharePoint farm solution with a couple of feature staplers (FeatureSiteTemplateAssociations) that fire for all templates (“GLOBAL”) at either the farm or web application level. On creation of a new site collection or site, the feature staple fires and looks up the regional settings of the root web at the root site collection for the web application, and then copies those settings to the current web (SharePoint site).

 

Manage Farm Features or Web Application Features

Code!

First off, here’s the code for the payload – the method to do the copying.

/// <summary>
/// Sets the locale for web.
/// </summary>
/// <param name="web">The web.</param>
public static void SetLocaleForWeb(SPWeb web)
{
    try
    {
        // find the Uri of the current web
        Uri currentWebUri = new Uri(web.Url);
        // work out the Uri for the root (e.g. 
        // http://webapp1/sites/site1/subsite1 becomes http://webapp1)
        UriBuilder rootWebUri = new UriBuilder(currentWebUri.Scheme, 
            currentWebUri.Host, currentWebUri.Port);
        string rootSiteUrl = rootWebUri.ToString();
        // attempt to change the locale / regional settings by running as system...
        SPSecurity.RunWithElevatedPrivileges(delegate
        {
            // ...to access the root site/web of the web app
            using (SPSite rootSite = new SPSite(rootSiteUrl))
            {
                using (SPWeb rootWeb = rootSite.RootWeb)
                {
                    // ...and change the locale and regional settings of the current site
                    // to those of the root site collection root web's.
                    web.Locale = (System.Globalization.CultureInfo)rootWeb.Locale.Clone();
                    web.Update();
                    web.RegionalSettings = new SPRegionalSettings(rootWeb);
                    web.Update();
                }
            }
        });
    }
    catch (Exception ex)
    {
        LogError(System.Reflection.MethodBase.GetCurrentMethod().Name, 
            ex.Message, ex.StackTrace);
    }
}

And here’s the code that’s run on FeatureActivated at the Web level (and a similar one at the Site level):

/// <summary>
/// Occurs after a Feature is activated.
/// </summary>
/// <param name="properties">An <see cref="T:Microsoft.SharePoint.SPFeatureReceiverProperties"/>
/// object that represents the properties of the event.</param>
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    if (properties.Feature.Parent is SPWeb)
    {
        SPWeb web = (SPWeb) properties.Feature.Parent;
        Utilities.SetLocaleForWeb(web);
    }
}

Next, we need to create a a feature to do the stapling itself. This should include an element manifest (or elephant) with FeatureSIteTemplateAssociation nodes.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!--Web-level feature-->
  <FeatureSiteTemplateAssociation 
    Id="dd5923f9-05a4-4d6a-a78f-0dd8b08ff079" 
    TemplateName="GLOBAL" />
  <!--Site-level feature-->
  <FeatureSiteTemplateAssociation 
    Id="54fa6d42-c145-49dc-b2eb-f5db548bc111" 
    TemplateName="GLOBAL" />
</Elements>

Once again, don’t forget the full project and source code is available on CodePlex here: http://slash.codeplex.com.

Enjoy!

Technorati Tags: SharePoint, SharePoint 2010, SharePoint Administration, SharePoint Development