This is the fourth entry of my PowerShell for SharePoint Admins series. I am basing this series on what SharePoint Administrators have said are the most important tasks to accomplish in PowerShell. Here is the list:
Create/Delete Sites, Webs and Web Applications
Backup and Restore Sites, Webs and Web Applications
Deploy Solutions and Features
Configure Service Applications
Manage Content Databases
Manage Timer Jobs
Manage Content Deployment
In this session we are continuing on in our quest to become proficient in this shell language. So now that we’ve created a SharePoint site in our last session, we need to do what every responsible administrator should do: back it up. Now HERE is where there is no denying that PowerShell is the way to go. Even for us OSITAs…you *can’t* say that PowerShell in this case isn’t the preferred method (well, you *could*, but you’d be lying).
Let’s bring up the site:
Let’s add a doc to the default ‘Shared Documents’ document library.
So to back up our site type the following in our pretty blue PowerShell prompt and type the word back and try that cool trick we did last time (hit the tab key) and you should see this:
Nice; but we don’t want to back up the configuration database, so hit the tab key again. hmmm..SPFarm…no, hit the tab key again. YEAH!! Now we’re talking! The command should now say Backup-SPSite. Now we want to back it up to a folder somewhere. Since all we have is one doc (and this is a demo) let’s save it the c:\temp directory. Normally we would have network share where we store our backups, right? RIGHT?
Ok, so now you have Backup-SPSite, hit the space bar and then hyphen and hit the tab key. Identity? Yeah, its asking for the URL. So in our case type in the url WITH the port number. Then you will hit the space bar and then type a hyphen and the tab key until it asks for PATH. Type in c:\temp\osita.bak . So now you should be ready and the entire command should look like this:
|Backup-SPSite -Identity http://osita.com:8080 -Path c:\temp\osita.bak|
Yes, there are a lot more parameters that we could use, but we will get to that later in the series. Right now just hit ENTER. Wait for it…and it’s done. OK now we can get crazy! How crazy? Delete the site. Yup…and you know what? Do it from the GUI…go ahead, I’ll let you digress and use the GUI this ONE time. There, feel better?
OK, so now from the pretty blue PowerShell prompt, type Get-SPDeletedSite and hit enter. You should see something like this:
Now..if PowerShell gives you grief—it’s probably because you have upgraded to SP1 yet. This command is new with SharePoint SP1. So—for those of you who haven’t yet deployed SP1, sit back for a bit—don’t worry, we’ll restore your site using a cmdlet that you can use—just hold tight and watch some cool stuff here..
OK, you see all those GUIDs? You will need to pay attention to the SiteID one. SharePoint kept track of all of the site collections we deleted (well, in our case just one). Now type the following command and hit enter and then ‘Y’ to confirm:
And voila! Your site was restored. Was that cool, or what? I know…you’re saying “Why did you want me to pay attention to the SiteID if I wasn’t going to need it?” You will in a minute but first let’s bring back our friends who have yet to plunge into the goodness that is SP1. OK, Pre-SP1 people—are you ready? At the prompt type the following command below, BUT DON’T HIT ENTER!!:
|restore-spsite -Identity http://osita.com:8080 -Path c:\temp\osita.bak -Force -Confirm:$false|
Let’s walk through this: the restore-spsite piece you should understand by now. -Identity is telling PowerShell what name of the URL (later I’ll show you how to change the name of a site), –Path is telling PowerShell from where to get the backup file, –force is saying “I don’t care if there is a lock or not on the db (there isn’t), just do it”, and the almighty –Confirm which I added a :$false which is telling PowerShell, “Do not ask me if I am sure that I want to do this; I am!”
NOW hit Enter.
OK…for those without SP1, now would be a good time to upgrade. I don’t want to have to type in separate instructions depending on version. What do you think this is, TechNet?
Now let’s *suppose* that you wanted to remove EVERYTHING: Web Application, Content Database, IIS Web Site, the whole shebang. OK—so here is what you would type:
|Remove-SPWebApplication -Identity http://osita.com:8080 -RemoveContentDatabases -DeleteIISSite -Confirm:$false|
Let’s walk through this: Remove-SPWebApplication –Identity is self-explanatory. Now there is another parameter that they *say* is required that is not in the above command—Zone. Had I had another URL in another zone with the same name (which could happen if I needed it for multiple auth, for instance), it would have deleted THAT one, too. In this case we only had one in the Internet Zone. So best practice would be to SPECIFY the Zone in your command. The –RemoveContentDatabases –DeleteIISSite is also self-explanatory. You already learned –Confirm:$false…look at THAT! You are already becoming an expert! <sniff, sniff> I’m so proud of you…
For our next session we will learn some PowerShell cmdlets that will give us some flexibility in being able to accomplish the Top Ten things SharePoint Admins use PowerShell for. Stay tuned.