BPC: ‘SharePoint 2010: An Administrative Odyssey’ with Lori Gowin

BPC: ‘SharePoint 2010: An Administrative Odyssey’ with Lori Gowin

by | Aug 26, 2010 | SharePoint 2010

Lori Gowin, a founding member of Women in SharePoint, presented a session titled "SharePoint 2010: An Administrative Odyssey" on the topic of, not surprisingly, administration in SharePoint 2010 at the BPC this afternoon.  Lori, a self-professed fan of SF, cleverly referenced HAL from 2001: A Space Odyssey throughout her session ("Just what do you think you're doing, Dave?"), and warned session attendees upfront that this was "a session for admins and what admins can do in Central Admin with SharePoint 2010." 

I'm not an admin myself, but I'm here to share some of what I learned from Lori's session all the same.  Needless to say, any errors in this post are entirely Lori's fault my own.

In contrasting Central Admin between 2007 and 2010, Lori flatly stated that "In 2010, for an administrator, what you need is right there at your fingertips."  And with that, Lori jumped right into the first of several demos she was to present during her session, showing how to extend a Web app.  In regard to the management of permission and user policies, Lori recommended that you not modify the default policies, but that if you have to do so, to use caution.  While demonstrating how to extend a Web app, Lori explained that the primary reason to do so is for purposes of authentication, taking pains to point out that "authentication does not equal permissions."  When extending a Web app, you're using the same content as the original app, so "it's not going to give you different security" just because it's a different URL.  Once complete, however, the extended app provides additional configuration options for authentication.

Lori shared a couple of best practices for Web apps, such as: limit the number of Web apps (they consume resources) and, as mentioned previously, use caution when modifying permission policies because you could adversely affect both object caching and the ability of search to crawl.

Items of note Lori mentioned regarding email and text messages in SharePoint 2010 had to to with outgoing email ("relay through SMTP server"), incoming email ("must set up SMTP on the server"), and text messages ("must have an account").  Regarding text messages, Lori also cautioned that since there is no throttling, it "gets expensive really fast."

Regarding farm management, Lori pointed out that alternate access mapping is the same as with application management; farm features represent "components you can reuse throughout the farm"; farm solutions represent packages; and user solutions equate to sandboxed solutions, which Lori referenced as being "a dev thing," but one of which she heartily approves due to the fact that sandboxed solutions make it all but impossible for a solution to bring down the farm.

On the topic of monitoring, Lori discussed the Health Analyzer, a best practices analyzer built right into Central Admin in SharePoint 2010, with timer jobs shown including visual representations in the form of progress bars, as well as various reporting methods.  Lori mentioned that the Analyzer is rule-based, scans periodically, and that rules can be adjusted according to the needs of farm administrators, and some rules can even be set to auto-correct.

Lori then demonstrated the Analyzer in action, going into Central Admin and showing that the Analyzer bar appeared in yellow since it included a warning message regarding verbose trace logging (since Lori had intentionally set it thusly in order that the Analyzer would discover it).  Clicking the warning message refreshes the page to provide more details on the issue, as well as provide the suggested solution.  As well, Repair Automatically appears as an option, and Lori demonstrated that feature, showing that the Analyzer warning disappeared once the verbose trace logging issue had been repaired automatically.  Lori cautioned, however, that you  probably wouldn't want to use this feature in the case of trace logs, at least not without first having saved the logs, since when you use the Repair Automatically feature, it doesn't tell you what is being changed.  In other words, use caution if you use this feature.

Speaking of logs, Lori shared the following best practices recommendations for logging: "change where logs are written (default is the C: drive – yikes!); limit disk space usage; turn Verbose on only when needed, then back off; back up the logs; and enable Event Log Flooding Protection (EVFP)."

Regarding timer jobs, which "perform a task on something that needs to happen in your farm," or, in short, "they keep SharePoint running," Lori's best practices recommendation on the subject is to "review your timer jobs [regularly] so you know what's going on in your farm."      

In discussing backup and restore options, of which there are two (farm or granular), Lori pointed out that the label "granular" is somewhat misleading.  As she put it, "Don't let them fool you: it's not quite item level."  Granular, in fact, pertains to backup and restore functionality at the site collection, site, list and library levels.       

Discussing managed accounts, Lori performed a demo to configure a managed account to underscore her point that "SharePoint is now aware the passwords need to change sometimes."  In her demo, Lori added a new managed account and configured the password management settings, then showed how easily those settings are editable from the managed accounts area in Central Admin.

On the subject of upgrade and migration, Lori said of patching that "You can only be one patch behind" in applying patches to servers without having first applied them to your databases.

Lori concluded her session with an overview of other admin tools, including a demo of the final one.  Beginning with PowerShell, she said, "Devs like it … and I'm embracing it."  Lori said that using PowerShell is itself a best practice, because "STSADM is going away, and you have more flexibility with PowerShell."  The other tool that Lori discussed as being an admin tool is the Developer Dashboard which is an out-of-the-box feature of SharePoint 2010, and which is for troubleshooting and is controlled with STSADM or PowerShell.  Despite its name, Lori believes that the Developer Dashboard "is not really a dev tool, it's an admin tool, something we need to use on a regular basis" for troubleshooting.

Check out ourfull coverage of Best Practices Conference 2010:

Get a Demo
Contact Us
Newsletter Signup