Beginning PowerShell for SharePoint 2013.pdf

(17430 KB) Pobierz
www.it-ebooks.info
For your convenience Apress has placed some of the front
matter material after the index. Please use the Bookmarks
and Contents at a Glance links to access them.
www.it-ebooks.info
Contents at a Glance
About the Author �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½
xvii
About the Technical Reviewer �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½
xix
Acknowledgments �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½
xxi
■
Chapter 1: Introduction �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½1
■
Chapter 2: What’s New in PowerShell for SharePoint 2013�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½9
■
Chapter 3: Configuring Your Environment for PowerShell �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½19
■
Chapter 4: PowerShell Basics�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½31
■
Chapter 5: Installing & Deploying SharePoint with PowerShell �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½51
■
Chapter 6: Managing SharePoint with PowerShell �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½77
■
Chapter 7: Managing Apps and Solutions Using PowerShell�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½113
■
Chapter 8: Administering and Monitoring SharePoint with PowerShell �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½139
■
Chapter 9: Managing Office 365 SharePoint Online with PowerShell�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½157
■
Chapter 10: Upgrading from SharePoint 2010 to 2013 Using PowerShell �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½181
■
Appendix A: PowerShell Cmdlets �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½193
Index �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½203
v
www.it-ebooks.info
Chapter 1
Introduction
The concept behind
Beginning PowerShell for SharePoint 2013
is an idea I’ve been holding on to for a few years now.
In every technology stream you look at, there’s always a clear distinction between administrators, referred to as IT
Pros in the Microsoft world, and developers. Administrators often think of developers as taking too many risks and
not considering the overall impact that their solutions may have on the system as a whole. They also don’t like the
fact that they don’t have control over what is being executed by the code provided. I can’t tell you how often I’ve seen
developers provide administrators with command line executables for them to run on SharePoint servers in order to
fix some issues with the SharePoint farm. On the other end, developers tend to think of administrators as being too
restrictive and always trying to put sticks in their wheels. I’ve seen this everywhere I’ve worked in the past, and I’m
sure most readers can picture themselves in this situation.
PowerShell brings the best of both worlds, allowing administrators to view in clear text what is being executed
as part of a script, and letting developers reuse their knowledge of the SharePoint object model by writing reusable
modules and methods. It doesn’t require users to compile any code, and it is leveraging all of the power of the
Microsoft .NET framework. The goal of this book is to try to bridge the gap that exists between SharePoint IT Pros and
developers by giving users tools to be able to deploy, manage, and monitor their SharePoint environment themselves.
At the end of the book, users will be able to perform most operations that are available through the Central
Administration interface or through the SharePoint object model, by developing their own flexible and reusable
PowerShell scripts.
The SharePoint Challenges
In every IT organization, it is very common to find a clear distinction between the developers and the administrators.
Developers create new modules and functionalities for systems, and administrators are responsible for implementing
and deploying them to production environments. Administrators are also normally in charge of configuring and
maintaining the environments where these solutions have been deployed. In many cases, developers are creating
solutions without really getting a grasp of what their solution will imply from a configuration perspective. They give
the administrators the instructions to implement their product and off they go. Even in the SharePoint world, this is
often the case.
I’ve worked in several different IT organizations that have been dealing with the technology, and I’ve seen many
cases in which administrators have to perform hours of manual intervention to properly configure solutions across all
sites in a SharePoint environment. To give you a concrete example, think of a scenario in which a development team
creates a new web part that needs to be added to all existing webs in an environment. This is a typical scenario, but
what if the environment includes 10,000 webs spread across multiple site collections? To think that someone is going to
go through each of these and manually add the web part is pure craziness. This type of situation highlights the need for
a solution that would let administrators responsible for implementing solutions automate tasks in a repeatable fashion.
I remember my first ever SharePoint-related assignment. I was then responsible for my organization’s internal
SharePoint 2003 environment. We had well over 25,000 webs across various site collections. My job was to activate
the French language in the regional settings in each of them. My team and I ended up creating a custom console
application that was using the SharePoint 2003 object model to loop through each site collection, go into every web
1
www.it-ebooks.info
Chapter 1
■
IntroduCtIon
and activate the language setting. This console application was being compiled as an executable file (.exe) and had to
be executed directly on the SharePoint server for it to be able to properly communicate with the various components.
My job as a developer was to produce this executable file, and to hand it over to the environment’s administrators,
who had no clue what my executable really was doing in the backend. They had to trust me that it did exactly what
I said it would, and that it wouldn’t impact servers for which they were accountable. It was like a black box; you
couldn’t view what was in it. Double-clicking these executable files to initiate the processes was always a very stressful
process. Administrators like to be in control and know what is going on. That is just the nature of the beast. At the
time, we implemented all of our “repetitive” configuration processes using this methodology. We ended up with over
20 such executable files, and nobody knew for sure exactly what each of them were doing without opening their code
in Visual Studio and figure out the execution flow. What a mess that was. Other than the fact that this process made it
tough on the administrators to identify what was being done to their environments by an obscure piece of software,
the only way you could create such a repetitive configuration task was to know how to code. You had to be a .NET
developer in order to find your way through the object model.
When PowerShell came around, near the end of SharePoint 2007 product’s life, it was like a revelation. Now,
we could have the same repetitive configuration tasks being executed against the server, but they were no longer
contained in these black boxes that were the console applications. They were now stored as plain text PowerShell
scripts that administrators could open to take a peek at the logic they contained. For the record, PowerShell scripts
are stored as .ps1 files and can be edited using any text editor software. I personally use Notepad for all my scripts,
but there are some other good free alternatives that offer advanced features such as the automatic completion of
commands’ names after a few characters to help speed the writing process. The problem, however, was that if you
didn’t know your way in the .NET programming world, chances were that you would be totally lost in the code.
SharePoint 2007 did not provide any PowerShell methods to interact with its components. You had to load the
SharePoint assemblies in your PowerShell sessions and interact with the .NET objects directly. It was basically the
same as writing your code in Visual Studio.
SharePoint 2010 then came to the rescue. It offered what we can call shortcut methods, orcmdlets (pronounced
command-lets),
that allowed users to interact with various SharePoint artifacts in a very straightforward and easy
way. For example, assume that you are trying to get the title of a specific SharePoint web in your environment. In the
SharePoint 2007 world, this had to be achieved using the something similar to the following lines of PowerShell:
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = New-Object Microsoft.SharePoint.SPSite("http://localhost")
$web = $site.RootWeb
$title = $web.Title
Using PowerShell with SharePoint, the same operation can now be achieved using the following two lines of PowerShell:
$web = Get-SPWeb http://localhost
$title = $web.Title
This new way of using PowerShell to interact with SharePoint not only made the scripts simpler, it also made
them more readable. Administrators wanting to write scripts no longer had to know the SharePoint object model
inside-out in order to build powerful PowerShell scripts (although it definitively helped).
PowerShell is not just for administrators, however. Complex scripts might still require some level of programming
skills in order to be completed. In many organizations, developers are still responsible for writing the PowerShell
scripts for maintenance tasks. This is an interesting paradigm, because it forces them to be aware of how the
administration modules of SharePoint actually work. If you want to have a PowerShell script developed for your
organization that automates the creation of hundreds of crawled properties for your SharePoint search engine,
the developer writing the script will need to understand the various search administrative components in order
to properly develop his script. This means that, on one end, we need administrators to start understanding some
high-level programming concept and understand the SharePoint object model to some level, and, on the other end,
we have developers that need to be more open-minded about the administration aspect and learn how to properly
configure administrative components of SharePoint. Figure
1-1
illustrates this concept.
2
www.it-ebooks.info

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin