Create SharePoint Groups with PowerShell

@webdes03 #SPSVB Could use help coming up w/a script to make 110 SP Groups for 1 Site collection. Have time to help?

January 10, 2012 21:33 via webReplyRetweetFavorite

@java_woman

Rebecca Ward

It wasn’t until I looked into this tweet that I realized there was no “New-SPGroup” type cmdlet that ships with SharePoint out of the box. Instead, we have to call the SiteGroups.Add operation on the web where we want to make the group. While this isn’t terribly intuitive for people new to PowerShell, this post should help to walk you through it.

Firstly, we’re adding groups to webs, not sites, so we need to identify the web where the group is going to exist. While groups are available site-wide, they’re actually stored at the web level, which explains why when you create a subsite (a web), you get the three default groups created. Yes, I realize it’s confusing that a web has a property of “SiteGroups”, and a site doesn’t–but that’s just the way it is. Before we can do anything, we need to create a variable and save our web object into it.

$web = Get-SPWeb http://intranet

In addition to a title and description, we also need to specify the owner and any members of our group when we call the SiteGroups.Add operation; those users must be valid SPUser objects, not a “domain\username” string. To keep things simple for this example, let’s assume they’re the same person, since the owner is typically also a member of the group. We’re going to create a user variable, and pipe our web object to the Get-SPUser cmdlet (with a user string). This will tell PowerShell to iterate through every user in our web until it finds the one we’ve specified, and save that SPUser object to our user variable.

$user = $web | Get-SPUser "domain\username"

Now that we have our user captured, we can go ahead and call the SiteGroups.Add operation, passing to it the title of the group, the owner of the group, the members of the group, and the description of the group (in that order).

$web.SiteGroups.Add("Group Name", $user, $user, "Group Description")

Now it’s a simple matter of heading on over to your groups list and validating that it’s there.

If, like Rebecca, you had a lot of these to do, you could store the details in a CSV file and handle your inputs from there. Let’s assume you had a CSV with columns of “Web”, “GroupName”, “User”, and “GroupDescription” that was stored in C:\Groups.csv, we can make a simple script to loop through all of the lines in the Groups.csv file and create each group.

$groups = Import-CSV c:\Groups.csv
foreach ($group in $groups) {
	$web = Get-SPWeb $group.Web
	$user = $web | Get-SPUser $group.User
	$web.SiteGroups.Add($group.GroupName, $user, $user, $group.GroupDescription)
}

Validate Application Pools & Identities

I ran into a scenario where I needed to validate what application pool and identity a particular service application was running as. While you can do some round about poking through the UI or through IIS, it’s also pretty simple to grab this information using PowerShell.

Service Applications
First things first, we need to grab a list of all of our service applications. We can skip this step if you already know the name of your service application.

Get-SPServiceApplication

Get-SPServiceApplication will output a list of all service applications configured on your farm. You’ll notice that by default you see three columns (DisplayName, TypeName and Id). As a result of the three columns, PowerShell will truncate the contents of the columns to allow them to all display. This means that if you have long service application names, you probably won’t see the full name. To get around this, we can specify the column(s) we want to see.

Get-SPServiceApplication | Select DisplayName, Id

Once you’ve identified the service application you want to validate (or if you already knew it), we can create a variable containing all of the properties for that particular service application. The “Identity” parameter should match the DisplayName of the service application.

$serviceApp = Get-SPServiceApplication -Identity "My Service Application"

Alternatively, you can also use the GUID to select the service application.

$serviceApp = Get-SPServiceApplication 00000000-0000-0000-0000-000000000000

Now that we have our $serviceApp variable containing all of the properties for our service application, we can view (or set) any of the available properties. The Get-Member cmdlet allows us to view a list of all objects, properties and methods that are children of the current object. In this example, it would list all of the objects, properties and methods of our selected service application.

$serviceApp | Get-Member

We can now determine the application pool and the identity of that application pool by viewing the ApplicationPool property of our service application.

$serviceApp.ApplicationPool

Web Applications
Much like we did with service applications, we first need to identify the web application that we want to work with.

Get-SPWebApplication

Get-SPWebApplication will output a list of all web applications configured on your farm. The nice thing is that web applications are a little more intuitive because we can use the URL of the web application to identify it, and that’s almost certainly something you’re going to know off the top of your head. Once you’ve identified the web application you want to validate, create a variable containing that web application.

$webApp = Get-SPWebApplication http://mywebapp.corp.tld

Just like we did with our service application, we can use the Get-Member cmdlet to list all of the objects, properties and methods of our web application.

$webApp | Get-Member

We can now determine the application pool and the identity of that application pool by viewing the ApplicationPool property of our web application. Note that Microsoft hasn’t been this consistent throughout SharePoint as a whole, and there’s a lot of cases where you’ll find differences between property names on objects where you’d think they would be the same. Learn to love the Get-Member cmdlet, which will always show you what you’ve got to work with.

$webApp.ApplicationPool

Executing all SharePoint 2010 Health Analyzer Jobs

One of the most useful lines of PowerShell script (as far as SharePoint 2010 goes) has to be the ability to kick off all of the SharePoint Health Analyzer timer jobs in one shot. This single-line of PowerShell is something you should always have in your back pocket, whether you’re validating a newly built farm or performing post-maintenance testing. Once you’ve loaded the SharePoint snapin, simply execute the following line of PowerShell, then surf over to Central Administration to check the farm health.

Get-SPTimerJob | Where {$_.Name -like "*Health*" -and $_.Name -like "*-all-*"} | Start-SPTimerJob

Understanding Objects, Properties and Methods

As I said in the first post of the series, we will be using PowerShell to interact with SharePoint object model, so we do need to spend a few minutes talking about the differences between an object, a property and a method.

In simple terms, a method can be thought of as a subroutine or a function. Many objects in the SharePoint object model have “precanned” methods attached to them, we’ll come back to this in a later post in more detail.

An object is an element within the object model. Objects are comprised of one or more objects and/or properties. I have always found it useful to conceptually relate objects and properties to XML—objects would be nodes of your XML, and properties would be individual attributes on your nodes. If you were to apply this concept to the photo below:

• The house is an object
• The color of the house (blue) could be a property of the house
• The number of windows (3) could be a property of the house
• The door could be an object of the house
• The color of the door (blue) could be a property of the door

An Introduction to PowerShell

This marks the first post in a new series on using Windows PowerShell with SharePoint 2010 (possibly the best marriage of concepts since Hewlett and Packard—a befitting reference given all of the mention of WebOS in the news this week).

In order to take advantage of the true power of PowerShell (no pun intended), you need to have at least a little bit of background on how to get started. While we will be using the SharePoint 2010 object model with PowerShell, you don’t need to be a true developer to take advantage of (some of) the powerful capabilities contained within the beast. As we progress toward the path of writing our own cmdlets and such, the discussion will inevitably turn more dev-focused, but for now let’s focus on the basics.

PowerShell as a Technology

Windows PowerShell is just that, a “Windows” product. In fact, it’s the native Windows management shell, not a technology that’s unique to SharePoint. The nice thing about this is that we can use PowerShell to interact with Windows components, such as services and operating system configuration, in addition to Active Directory, SQL, and other products (including SharePoint).

PowerShell vs. SharePoint Management Shell

If you’ve been poking around on your SharePoint server, you may have noticed that you have two separate shell’s on your system—PowerShell itself, and the SharePoint Management Shell . Aesthetically, the only difference between the two is that the SharePoint Management Shell is black (which gives it more of a command prompt look), and the PowerShell console is actually blue. Both consoles are technically PowerShell, and I’ve got no idea why the SharePoint one is black—unless it was simply to ease the transition from STSADM to PowerShell.

You can open the SharePoint Management Shell from the “Microsoft SharePoint 2010 Products” folder in the start menu. Native Windows PowerShell can be opened either via the PowerShell icon on the task bar, or by navigating to “Accessories” -> “Windows PowerShell” from the start menu.

Functionally, there are a few differences under the covers. When you load the SharePoint Management Shell, it will automatically load the necessary SharePoint components without you having to do any additional steps. In short, you can open it up and fire away. The native PowerShell console won’t (by default) load the SharePoint components, so if I were to open PowerShell and execute something like a simple Get-SPSite command, I’d be greeted with a big red error message saying that it doesn’t know what the Get-SPSite cmdlet is.

So what are these “components” that are being loaded? PowerShell components are broken into two categories: Snapins and Modules. Snapins can be easily loaded by executing Add-PSSnapin and Modules can be loaded by using Import-Module. You can load a snapin anytime you need to, or you can build a custom profile for PowerShell that’ll automatically execute every time you load the console—loading the snapins and modules you frequently use (such as the SharePoint snapin).