I'm honored to be Speaking at the European SharePoint Conference 2013.

I'm speaking at the European SharePoint Conference 2013 and I’m delighted to be a part of this fantastic gathering of the SharePoint Community, Feb 4-7 2013, in Copenhagen, Denmark.

I will be conducting two sessions – “SharePoint & ADFS - Federation Made Easy” and “What's New with Powershell V3 for SharePoint 2013 Admins” both aimed at IT Professionals.

SharePoint & ADFS - Federation Made Easy

Supporting authentication and authorization for SharePoint can be challenging, especially if you have partner organizations involved. Claims-based authentication provides you with the ability to authenticate across multiple platforms. Come to this session and learn how the two products come together in order to support federation.

What's New with PowerShell V3 for SharePoint 2013 Admins

PowerShell made a huge difference in the administration of SharePoint 2010 with the inclusion of the SharePoint Management shell, and now there are over 100 new cmdlets for SharePoint 2013! Come and see the new power that PowerShell offers with the new version of SharePoint.

I am speaking alongside renowned experts on SharePoint as well as sharing the stage with some of Microsoft's product team from Redmond covering Search, Apps, Social, Cloud, Project, Migration & Upgrade, Governance and much more.

With over 110 SharePoint sessions, keynotes, hands on labs, SharePoint Shootouts, ask the experts, community lounge, tutorials, Europe's largest SharePoint focused expo, SharePints, parties, meetings, networking events, competitions and more....  this is a MUST attend event for all SharePoint enthusiasts! Check out the full Conference Programme to see all sessions and topics that are being covered by myself and many others.

Prices start as low as €995! There is also special group discounts for bookings of 3 or more people.

Book Now and I’ll see you in Copenhagen this February.

1. Create/Delete Sites, Webs and Web Applications

2. Backup and Restore Sites, Webs and Web Applications

3. Deploy Solutions and Features

4. Add/Delete Users

5. Logs

6. Configure Service Applications

7. Manage Content Databases

8. Manage Timer Jobs

9. Manage Content Deployment

10. Manage Search

SharePoint service applications

From MSDN: The Service Application Framework provides over 20 services that are built into the core product. For example, SharePoint Search is implemented by Service Application Framework. The Service Application Framework is an API that is provided to build services that are hosted by back-end application servers and consumed by front-end Web servers.  The Service Application Framework replaces the Shared Services Provider in Microsoft Office SharePoint Server 2007. The Service Application Framework model is much more flexible than the Shared Services Provider model. Service applications can be used by a single server farm or shared across farms, allowing centralized shared computing investments. Service Application Framework applications are easily scaled out for load balancing high-demand service applications. 

A good write up on them by Spence Harbar is here; or you could also watch my video on them HERE.

Although neither of the previous links go into the installation and configuration at all, they do give a good overview of what they are and how they are implemented.  In this session we will install and configure them using PowerShell.

Scripting Hygiene

So, when I was learning scripting for the first time WAY WAY back in the 80s…the thing that helped me most was understanding what it was that I was trying to do and then mapping out the steps to get there.  The class I had asked us to write a script that had a figure get in and out of a car.  It taught us how to think methodically.  So in this session, we will look at the step by step process and write the corresponding script to get ‘er done.  Sound like a plan?  Let’s start:

When you start out writing PowerShell script (or anything) you should know that documenting is IMPORTANT.  Making comments in your code will not only help others who are reading your script, but also YOU who will eventually update it and wonder what you were thinking when you wrote a certain line or section.  So what I would suggest is start out in the PowerShell_ISE (or whatever IDE editor you want – I like NotePad++) and use the comment symbol ‘#’ to comment about what you are about to do.

So let’s start off with stating what this script does.  type the following into your editor.

# This script configures the Microsoft Managed Metadata Service Application

The absolute next thing you want to do is make sure that the PowerShell snapin is loaded (unless you are using the PowerShell_ISE that we configured to automatically load it—but we’ll handle it even if it is).  So skip a couple of lines down in your script and type the following:

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue

We added the parameter that will allow PowerShell to ignore the issue if the snapin is already loaded (-erroraction SilentlyContinue)

Now we want to add our variables for PowerShell to refer to in our script.  These variables are things such as server names, database names, application pool names, etc. so that we don’t have to keep typing them in over and over again.  Type the following a couple of lines below the last line you typed:

#Variables

$databaseServerName = SQL1
$AppPoolName = “AppPoolName”
$AppPoolUserAcct = “domain\appPoolAcct”
$ManagedMetadataName = “Managed Metadata Service Application”

OK, so now we’ve defined the variables.  Now we start writing the cmdlets that will configure the Service app.  We will group some of the cmdlets in between the  { } symbols.  Here are the next lines:

$AppPool = Get-SPServiceApplicationPool –Identity $AppPoolName

{

     $AppPoolAcct = Get-SPManagedAccount –Identity $AppPoolUserAcct

{ 
      Write-Host "Please supply the password for the Service Account..."
      $appPoolCred = Get-Credential $appPoolUserName
      $appPoolAccount = New-SPManagedAccount -Credential $appPoolCred  
  } 
  
      $appPoolAccount = Get-SPManagedAccount -Identity $appPoolUserName 
  
      if($appPoolAccount -eq $null) 

      { 
          Write-Host "Cannot create or find the managed account 
$appPoolUserName, please ensure the account exists."
    Exit -1 
  } 
  
  New-SPServiceApplicationPool -Name $saAppPoolName -Account 
$appPoolAccount       
} 

WHOA!  I threw a couple of new things in here.  Let’s talk about them.  First I threw the Write-Host cmdlet.  All that does is put whatever follows in quotes on the screen; kinda like ECHO.   The other thing I threw at you was the IF statement.  The way IF statements work is when you want the script to do something on the condition that something else is in place (or not).  In this script, we are telling the script that “If the application Pool account is blank….” (-eq $null means “Blank”) then what you do is to open a { symbol and put in what you want to happen.  In this case we want PoSh to print out on screen “Cannot create or find …..” and then to exit out.  That’s it.

OK, so what’s next?  We have set our variables, told PoSh to create an application pool for the service using a managed account and now its time to set the Proxy.

Write-Host "Creating Metadata Service and Proxy..."
New-SPMetadataServiceApplication -Name $ManagedMetadataName -ApplicationPool $saAppPoolName -DatabaseServer $databaseServerName -DatabaseName"MetadataDB"
New-SPMetadataServiceApplicationProxy -Name "$ManagedMetadataName Proxy"-DefaultProxyGroup -ServiceApplication $ManagedMetadataName
Get-SPServiceInstance | where-object {$_.TypeName -eq "Managed Metadata Web Service"} | Start-SPServiceInstance

Next, you save the file as ManagedMetadata.ps1 and you’re done!

In our next session, we will get down and do some security stuff – Adding/Editing Users and Groups!

This is the fifth entry of my PowerShell for SharePoint Admins series.  In this session we will learn some PowerShell cmdlets that will give us some flexibility in being able to accomplish the Top Ten things for which SharePoint Admins use PowerShell .  I am basing this series on what SharePoint Administrators have said are the most important tasks to accomplish in PowerShell.  Here is the list:

1. Create/Delete Sites, Webs and Web Applications

2. Backup and Restore Sites, Webs and Web Applications

3. Deploy Solutions and Features

4. Add/Delete Users

5. Logs

6. Configure Service Applications

7. Manage Content Databases

8. Manage Timer Jobs

9. Manage Content Deployment

10. Manage Search

In this session, as all the previous sessions,  we are continuing on in our quest to become proficient in this shell language.  We need to understand some of the “funny” symbols and stuff (remember, we’re OSITA’s and don’t want nuthin’ to do with “Codin’”) ---sigh…it’ll be OK, I promise.

Symbols

Most of the symbols used in PowerShell you’ve seen before and aren’t that new.  Some will be new, but I will attempt to make it as painless as possible.

! = NOT.  As in, if you see this symbol before something, it means NO/NOT/Does not exist.  Where would you see this?  Examine the following line:

(!(Test-Path $profile.AllUsersAllHosts))

This would read (in English) = If the “All Users All Hosts” profile directory does NOT exist….that’s all that means.

Next:

{ or } = block of stuff.  More or less.  When you want PowerShell to treat something as a whole. 

Here is an example:  

C:\> Get-SPWeb http://portal/* | where {$_.MasterUrl -like “*/v4.master”}

OOH…I slipped two on you that time!  I will explain both the {} (called curly braces) and the | (called a pipe).

In English the line above says, get all the sites (not site collections) that start with the URL http://portal/* (That is the Get-SPWeb)  and then when that is done (that is where the pipe (|) comes in), show wherever there are those that are using the v4.master page to me.

Next:

$ = variable.  This is self-explanatory.  Here is an example:

   1:  $SiteName = "Slick Rick's Site" 

   2:  $SiteUrl = "http://intranet.osita.com/sites/" + $SiteName   

   3:  $NewSite = New-SPSite –URL   

   4:  $SiteUrl -OwnerAlias Administrator -Template STS#0 –Name $SiteName  

   5:  $RootWeb = $NewSite.RootWeb

   6:  $RootWeb.Title = "Slick Rick's Site: " + $SiteName

   7:  $RootWeb.Update()

   8:  Write-Host "Site successfully created"

So what we have above is this: We are creating a variable named $SiteName and giving it the name “Slick Rick’s Site”.  So everywhere you see $SiteName, PoSh will stick in “Slick Rick’s Site”.  Follow that logic for each of the lines that begin with ‘$’.  Line 3 is a little different in that it is saying that the cmdlet “New-SPSite” will be substituted for $NewSite.  So you can see that even cmdlets/commands/actions can be used in variables.

OK, so now is your test.  Jeapordy-style.  I will give you the answer and then you will give me the question: 

“This script means:  If there is no entry for $FarmPassphrase or if the entry for $FarmPassphrase is blank, tell the user to enter one.

start-Music.Jeopardy
{
start-sleep 30
} 
stop-Music.Jeopardy

OK! The Question is:

What does the following line of script mean?

If (!($FarmPassphrase) -or ($FarmPassphrase -eq ""))
    {
        Throw " - You must enter a Farm Passphrase"
    }

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:

1. Create/Delete Sites, Webs and Web Applications

2. Backup and Restore Sites, Webs and Web Applications

3. Deploy Solutions and Features

4. Add/Delete Users

5. Logs

6. Configure Service Applications

7. Manage Content Databases

8. Manage Timer Jobs

9. Manage Content Deployment

10. Manage Search

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:

Restore-SPDeletedSite /

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.

1. Create/Delete Sites, Webs and Web Applications

2. Backup and Restore Sites, Webs and Web Applications

3. Deploy Solutions and Features

4. Add/Delete Users

5. Logs

6. Configure Service Applications

7. Manage Content Databases

8. Manage Timer Jobs

9. Manage Content Deployment

10. Manage Search

Oh and before I forget, my slide deck is posted here on SlideShare.

OK, so just so you know—blogging faithfully is a challenge for me; I will simply start a series. I thought that Part 3 was going to be the final piece but I can’t see doing the Top 10 all in one post—I just cant do that and post frequently, SO—I will devote a post each week to each of the Top 10. 

We are going to create a Web Application to house a site collection that will have a site which will house an external list (yup we will provision BCS using PowerShell—fun, fun). We will back it up, delete it, then restore it (all using PowerShell), install and deploy a feature, add a user, move the site from one content database to another, and much much more.

So as an OSITA (Old School IT Admin), this can seem like a tall order; almost a reason NOT to want to use PowerShell because, well…I HATE coding or having to learn how to do ALL THAT at the command line. Well, don’t fret my fellow Admins—it’s not THAT BAD—actually not bad at all. I promise you, once you learn a few things it will become second nature to you, just like typing CLS to clear the screen or DIR to get the directory.

Create/Delete Sites, Webs and Web Applications

Yes, you can.  You can create a site via Central Admin and you ask “So why would I ever use PowerShell to create a site?”  I can think of two reasons: a) you can’t get to CA for some unknown reason or b) you try and it doesn’t work.  Let me give you a couple of scenarios:

You are a SharePoint admin and you need to create a site for a group that is impatient.  From the time you receive the request they are knocking on your door (like you don’t have a million other things to do) and so you say, fine—how long can this take?  You type in the URL for Central Admin and it churns….and churns…hmmm, you say..that’s strange.  You close the browser and try again.  Nada.  hmmm..you RDP into the server and try from there.  503 error.  You go to IIS and see what’s up and the phone rings “Is it done yet?” 

It probably took you 30 sec or less just to read the above paragraph, but it would have taken you much longer to actually do what the paragraph says.  In that same amount of time you could have simply typed a simple cmdlet and been done with it.

Here’s the second scenario:  You are a SharePoint admin and you need to create a site for a group that is impatient.  Same thing…except CA works, but when you try to create the site, it fails.  Multiple times.  Multiple templates.   Ok, so let’s say that for some reason the Timer Job Service is off and won’t turn back on.  What do you do?  You could spend time on working on that while the group keeps calling you or knocking on your door OR you could simply type a simple cmdlet and be done with it.

You see what I’m getting at?  PowerShell will save you TONS of time and it’s SIMPLE.  Especially creating sites.  Here is how you do it:

Go to the run command and type PowerShell.  OOOH, what a lovely blue background (for those who read and followed the previous post).

We will create a web application to host our site collection.  Let’s call our Web Application OSITA.com.  (If you are following this post by doing the exercises, make sure you put an entry in your hosts file so that this works).

Cool Tricks

So at the PowerShell prompt, type:  New-SPWeb and hit the TAB key until the entire cmdlet reads: New-SPWebApplication.  Then put a space after it, type a hyphen and hit the TAB key once more.  What you should now see is the following:

New-SPWebApplication -Name

What this cool little trick does is help you put in the information that you need to make the script run without errors.  So, type in the name of the Web Application as “OSITA”, then type a space and a hyphen and hit the TAB key two times.  It should now ask for the Application Pool.  Let’s say OSITAAppPool.  So now the line should look like this:

New-SPWebApplication -Name OSITA -ApplicationPool OSITAAppPool

I can tell you’re liking this TAB key thing, huh?  You just keep hitting the TAB key to cycle through the various parameters and typing in the values. The parameters you really want to use in this example are the following:

-Name “OSITA”

-ApplicationPool “OSITAAppPool”

-Port “8080”

-ApplicationPoolAccount “<your app Pool account>”

-URL “http://osita.com”

When all those (and only those) parameters are typed in hit ENTER and it will churn for a little bit.  When it is all done you should get a display similar to the following:

DisplayName                    Url
-----------                    ---
OSITA                          http://osita.com:8080/

Now we are going to create a root site collection in this web application to use.  Let’s keep the name the same. Remember to keep everything in quotes.  Here is the list of parameters—I will let you type it all in using the TAB key trick I taught you above:

-Name “My First PoSH Site”

-URL “http://osita.com:8080”

-Template STS#0 (NOTE:  This does NOT go in quotes—this template is the Team Site Template, more on those later)

-OwnerAlias “<your_domain\your_username>”

-Description “Slick Rick taught me how to use PowerShell to create this site”

-Confirm:$false (Type that in exactly as you see it.   This will keep the prompt from asking you “Are you sure?”

OK, so for those of you who want a *picture* here it is:

New-SPSite -Url "http://osita.com:8080" -Template STS#0 -Name "My First PoSH Site" -Description "Slick Rick taught me how to use PowerShell to create this site" -OwnerAlias "mcc\rtaylor" -Confirm:$false

Now hit enter.  It will churn and then you’ll get the lovely confirmation that your site is now created.  But did it *really* work?  Open up a browser and type in the URL (including the port number) and see.

It should prompt you for credentials and after you do that….voila!  How cool is *THAT*!?  You’ve done it!  I recommend doing another and another until you are confident you have it down to a science. 

Next week: We’ll back up our site, delete it and then restore it.

OK, so why haven’t I posted the second part in so long?  LIFE.  No other reason.  So—on to the next part:

In Part I I told you that aliases were important and we wanted to make sure we didn’t have to remember what they were and to make them specific. OK, so that means we have to learn a little about PowerShell profiles.

Profiles

So what is a PowerShell profile?

The PowerShell profile is a text file that has a .ps1 extension. The extension is looked at by PowerShell as a script and the text in the script tells PowerShell how to act. In this file it will tell PowerShell what aliases it should remember, what snap-ins to load, what colors to use, etc.

OK, now to confuse you a little bit—there are four of these profiles. Here they are, what they are, and where they are located:

a. All Users Profile – This profile is located in the windows directory\system32\WindowsPowerShell\v1.0\profile.ps1. This one is the profile that gets loaded when anyone invokes PowerShell.

b. All Users Host Profile – This profile is located in the windows directory\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1. This is the profile that gets loaded when anyone using a particular shell environment invokes PowerShell. Think of this one as the profile that pertains to the machine regardless of user.

c. Current User Profile – This profile is located in the %userprofile%\Documents\WindowsPowerShell\profile.ps1. This is the profile that gets loaded by the current logged on user that invokes PowerShell.

d. Current User’s Host Profile – This profile is located in the %userprofile%\Documents\WindowsPowerShell\Microsoft.Powershell.ps1. This is the profile that gets loaded when a user invokes PowerShell on a specific machine. Think of this one as the profile that pertains Shell environment on a machine but is specific to the particular user that invoked PowerShell.

Why is that all important? Well, you need to know which profile to change if you want to be able to benefit from the change. if I want a change to be “Global”, I need to update *all four* of the profiles.

Configuring my PowerShell environment

I want to make sure of at least three things when I enter the PowerShell world: that I have blue background with yellow lettering, that my aliases that I set up are loaded and that the PowerShell snap-ins are loaded for SharePoint. So how would I do that? Here is how:

First thing is to find out where your profile is. Go to the PowerShell command prompt and type $profile. It will give you an output of %userprofile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 . Now attempt to go to that location; what do you see? Nada. Nothing. Zilch. Goose egg. Now type this at the prompt: ‘

Test-Path $profile

The output will be ‘FALSE’. So in order to “see” the path and the profile script that PowerShell is reading from type the following:

New-Item -path $profile -type file –force

The output will be

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---          8/5/2011  12:59 PM          0 Microsoft.PowerShell_profile.ps1

Now if you were to attempt to browse to the path, you would see it. Cool, huh? OK, before we go any further, let’s make sure our envrionment is set up to change the contents of this file. If you are on a Windows 7 machine, you are already good to go, but if you are on Windows Server 2008 R2, you will need to type this command in the console:

Import-Module ServerManager;Add-WindowsFeature PowerShell-ISE

After running those commands you should see the PowerShell ISE option as in the following diagram:

You will also see the following diagram if you were to right-click on the PowerShell icon on the taskbar:

OK, now right-click the file profile.ps1 script and click OPEN. This will open the PowerShell ISE you will notice that it is empty. This means that PowerShell will simply load into memory and display the console. But we want to make it behave in a certain way, remember? So—let’s do that—first we want to make sure that the SharePoint snap-ins get loaded every time so that we don’t have to type in that long command that we can never remember. So in the script type the following:

Add-PSSnapin.Microsoft.SharePoint.PowerShell

It should look like the following

Then click the green ‘RUN’ icon. It shouldn’t give you any errors, just load the snap-in for SharePoint. OK, now minimize this window and go back to the PowerShell console.

It’s just black with white text. You may like this—I don’t; and besides this will be good practice for you. (YES YES, I *KNOW* you can change all of that by right-clicking on the menu bar, yada yada—but you will thank me later for this)

Now, type Get-Host and click Enter. The output will look something like this:

Name             : Windows PowerShell ISE Host
Version          : 2.0
InstanceId       : e9c2a9ca-9ea3-4887-9067-f2e111b9db64
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterfaceCurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.Host.ISE.ISEOptions
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

OK, so we are looking at the UI property. This is what we want to change from the default to a blue background with yellow letters. How do we do that? Well let’s talk through it-- we know that we have to invoke the ‘Get-Host’ cmdlet and we have to address the property UI. There is a property *inside* of UI that talks to the colors and its name is RawUI. To find out what we are currently using we need to invoke that property. So— at the run command type Powershell, and then type the following:

(Get-Host).UI.RawUI 

Remember to use the parentheses here around Get-Host, or you will get an error message. The reason is that you first want PowerShell to get the local environment and then give you the properties. When you hit enter, you will see something like this:

ForegroundColor       : Gray
BackgroundColor       : Black
CursorPosition        : 0,1
WindowPosition        : 0,0
CursorSize            : 25
BufferSize            : 100,300
WindowSize            : 100,25
MaxWindowSize         : 100,48
MaxPhysicalWindowSize : 168,48
KeyAvailable          : False
WindowTitle           : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

OOOOOOH!!!! Now if this doesn’t get the wheels turning in your head, you’re more of an OSITA than I am, and you need to get with it!

So let’s change the colors. I hate the black background and gray/white lettering. I want a dark blue background with yellow lettering. So, how do we do that? Let’s walk through this-- you already know that the previous command we ran showed us what colors we were using, so all we have to do now is change them. So how do we *change* them? We know (Get-Host).UI.RawUI.BackgroundColor = Black; so let’s change it to Dark Blue. Simple—just remember that names must be in quotes and can’t have spaces. So, type the following and hit enter:

(Get-Host).UI.RawUI.BackgroundColor = “DarkBlue”

And the screen should look like this:

Notice how the background after the carriage return turned to dark blue? Now let’s change the lettering. Type the following and hit enter:

(Get-Host).UI.RawUI.ForegroundColor = “Yellow”

And you should see this:

Now clear the screen and what do you think? Now exit PowerShell and re-open it. What happened? Why did it go away? Because PowerShell loaded your profile. The changes we made pertained to our current session only and aren't yet part of your profile. So now let’s fix that. Type Notepad $profile and add the following lines of code:

set-alias wipe clear-host
wipe
(Get-Host).UI.RawUI.ForegroundColor = “Yellow”
(Get-Host).UI.RawUI.BackgroundColor = “DarkBlue”
wipe

Save the file and re-open the PowerShell command. How ‘bout *THAT*?!! Now, for the ‘coup de grâce’ – open up the profile.ps1 file add the line ‘Add-PSSnapin Microsoft.SharePoint.PowerShell’ and save the file. Exit the PowerShell editor and reopen it. For those of you who have SharePoint installed on your machine, the snapins are now loaded and you can type any SharePoint specific cmdlet and PowerShell will understand you. For those of you who do *NOT* have SharePoint installed on your machine, you might see a flash of red before the screen ‘wipes’ or clears itself because PowerShell can’t load the snap-in if the SharePoint dlls don’t exist. But no worries, you have a pretty editor screen in front of you.

In Part 3 (Final Part)  I talk about the Top Ten most common PowerShell actions for which a SharePoint Admin can use.

I’m not much of a VBScript guy, but I knew this could be done, so I sent her the following script:

Sub SaveToFolder(MyMail As MailItem)
Dim strID As String
Dim objNS As Outlook.NameSpace
Dim objMail As Outlook.MailItem
Dim objAtt As Outlook.Attachment
Dim c As Integer
Dim save_name As String

'Place path to sav to on next line. Note that you must include the
'final backslash

Const save_path As String = "<location where you want the file saved>"
StrID = MyMail.EntryID
Set objNS = Application.GetNamespace("MAPI")
Set objMail = objNS.GetItemFromID(strID)
If objMail.Attachments.Count > 0 Then
For c = 1 To objMail.Attachments.Count
Set objAtt = objMail.Attachments(c)
Save_name = Left(objAtt.FileName, Len(objAtt.FileName) - 4)
'save_name = save_name & Format(objMail.ReceivedTime, "_mm-dd-yyyy_hhmm")
Save_name = save_name & Right(objAtt.FileName, 4)
ObjAtt.SaveAsFile save_path & save_name
Next
End If
Set objAtt = Nothing
Set objMail = Nothing
Set objNS = Nothing
End Sub

To make this work for your Outlook client, you first need to enable the Developer feature in Outlook options:

Then go to Outlook and select the Visual Basic button

Select ‘Insert Module’

Insert the code in the code window:

At this point you simply create a rule (which will run locally and only when your client runs Outlook) which runs the script when you receive the attachment.

Then you are done! Every time you receive an email with an attachment, it will be stripped from the email and sent to the location you specified.  If you only want *certain* attachments to be stripped and shipped, then specify that in the rule.

So why, say some ITPros, are you blogging about PowerShell?  ITPros are very reticent about anything that resembles having to “code”.  Writing scripts is about as far as most are willing to go.  Most ITPros (the traditional administrator) feel most comfortable at the command prompt somewhere between traversing directories, to writing batch files to carry out unattended installation operations.  Some even feel comfortable at writing more complex operations using some scripting engine such as JScript, WScript, CScript or VBScript.  Some have written WMI scripts to manage their network environments.

What’s the Deal?

Most ITPros (myself mostly as well) say, “Why write code to do what I can do from the GUI even faster?”  For example, look at this:

strComputer = "DC01"

Set wbemServices = GetObject("winmgmts:\\" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_LogicalMemoryConfiguration")

For Each wbemObject In wbemObjectSet
    WScript.Echo "Total Physical Memory (kb): " & wbemObject.TotalPhysicalMemory
Next

A typical old school ITPro admin (OSITA) would say “PFFT…just hit Ctrl-Alt-Del !” (Well…an old school admin may not know what the script does, but you get the picture).  But what happens when I need to do something that, if I did it via GUI, would take F-O-R-E-V-E-R?  Here’s a scenario:

You are the administrator of Contoso Inc.  Your company has merged with another company, NWTraders and you need to import their users into your Active Directory database.  Their AD will be decommissioned.  They are explicit in their desire to simply created new users with new sIDs in Contoso’s AD.  NWTraders had 10,000 users.  A typical old school ITPro/admin (OSITA) would probably do one of two things:  a) Get a third party tool to do it, or b) find a script online that will do it.  Let’s modify the scenario and say Contoso will not pay for the third party tool. 

Now you’re stuck,  Mr./Ms Hard Core Old School ITPro/Admin.  What are you going to do?  What script will you use?  How do you know that it will work?  Here is a hint:  Learn how to script; fast.  As Shane Young and Todd Klindt have said in their traveling minstrel shows: It’s not that bad. (and neither are their sessions)  ;)

If you are like me, the quintessential ITPro, you have attempted to try to be a Dev once.  ONCE.  You took a few programming classes and at the end wondered why you wasted all that time trying to figure out how the new terms all fit together in any sort of coherent meaning.  Object, Class, Argument, pass, etc…WHAT?? 

My first official class in object-oriented programming was Visual Basic 3.  It was a 5-day course with the “Introduction” to VB being 2 days, the “Intermediate” being 2 days and “Advanced” being the last day.  Ha!  I held my own the first day, but struggled the second day.  I was totally lost the third day and playing solitaire by the fourth day.  I don’t even know why I even showed up on Friday.  I didn’t try my hand again until about three years later when I took VB6.  I was much better that time around and about four years after that I took ASP.NET.  #FAIL!

I was fine looking at code and knowing what it was intending to do, but to actually *write* something was just too….hard.  When SharePoint came around I knew I would have to pick it back up again, so I did.  I got a C# book and just hacked my way through it.  Not too hard, not my cup of tea—but meh…I did it.  When PowerShell came out, I said…hmmm…this isn’t so bad.  It’s like…batch scripting; almost—just more wordier.

The What

This brings us to “What is PowerShell”.  You’ve probably heard of PowerShell and if you are a hard-core, old school ITPro admin (OSITA)—you’ve been putting off learning it because you think, well, it’s almost like writing code.  Sigh…GET A GRIP!  You learned learned how to use DIR, COPY, MD, RD, and maybe even CHOICE—so learning a few more things won’t hurt…much.  I promise. And YES, it is important and YES you will need to know it because SharePoint 2010 administration will rely heavily upon it.

I understand your reluctance.  I do.  What I will attempt here is to walk you through a Pain-Free tutorial/primer in PowerShell for SharePoint. Powershell Primer for Serious Non-devs.  You know what they say: No Pain, No Gain—well, I am about No Pain, No Pain.

Again, most old-school ITPro admins (OSITA) were all about the “How”.  “Just show me how to do it so I can get on with more important things.”  I get that.  There is some value in knowing the “Why”.  This is where the OSITAs get tripped up.  The explaining in why this works.  While I promise not to go into the workings, I will explain in layman’s terms what is happening.  It’s important to know these things, because it helps in the long run when it comes time to build upon knowledge already garnered by previous experience.  For example, if I wanted to order a directory listing alphabetically and only a page at a time, I would type DIR /O /P.  I would know this only if I knew three things:  a)that DIR was the command for a directory listing, b) that there were parameters that I could type with DIR and c) How to find out what the parameters were  Same thing in PowerShell.  I will teach you something extremely simple, where to use it, what (if any) parameters you can use with the cmdlet, and finally how to find out if there parameters you can use with it.

The How

OK, so now for what the OSITAs have been waiting for—”Just show me the goods”.  Right. There are a few assumptions I will make:

a) I am going to assume you know NOTHING. Absolutely NOTHING. If you are a Dev here trolling for something…you are put on notice—this will bore you.

b) I am going to assume you have a Windows 7 workstation or a Windows Server 2008 machine to type from. Don’t gripe if it works differently in Windows XP, Vista or Windows Server 2003.

The first thing you need to know is how to get to the PowerShell command prompt. First, go to a command prompt and type ‘powershell’ (without quotes) as shown:

That will bring you to the PowerShell prompt.  How ‘bout that?

This is where you will finally see that things aren't so bad.  Most of the commands you are familiar with are available here; type DIR and see what happens.  Here’s one:  let’s create a directory for us to put our scripts into.  Remember how to create a sub-directory?  MKDIR or MD.  Call it scripts.  Your output should look like this:

Now change to the scripts directory.  Do you remember that command?  CD. 

So, right now you should be feeling pretty good and comfortable.  Nothing new so far.  So let’s show you something new.  Go back a directory and do a directory listings.  That would be typing ‘CD..’ and then typing ‘DIR’ like this:

Now for the new stuff.  In PowerShell, the command that does the same thing as DIR is ‘Get-ChildItem’.  Type ‘Get-ChildItem’ (without quotes).

Wow! You get the same thing!  So now you are thinking—“Why type all of that when DIR will suffice?”  Well, good question.  The point is to understand syntax so that building upon this knowledge will help you in the future.  So don’t just type dir anymore…use Get-ChildItem from now on. 

The Why

Get-ChildItem is a PowerShell cmdlet (yeah, I slipped that new term in) that does the same thing as DIR.   The way Powershell syntax works is a [Verb]-[Noun] pair.  In the previous demo, we told it what to do (verb) with GET, and then we told it what we wanted (noun) with ChildItem.  Let’s say we wanted to know the date.  We would tell the system what do with a verb (in this case GET) and what we wanted with a noun (in this case DATE).  Type Get-Date.

In PowerShell, syntax is very important.  Just know that when you want to use it, go at it with Verb-Noun and add any parameters you may need.  But what parameters are available?  Remember HELP ? In PowerShell, HELP is awesome!  But it doesn’t just stop at HELP.  Let’s say that I needed help on Get-Date.  Let me type help Get-Date and see what I get.  Notice what I point out in the help:

Yeah, you can actually get *examples* of how to use the cmdlet.  Let’s do this; type help Get-Date –examples >>get-date-example.txt  Why?  Because it will take what would normally print out on the screen and create a text file called get-date-example.txt and put that file in our scripts directory.  Using the >> sign will “pipe” screen output to a file.  More on “Piping” later.

After typing in the command you will get a text file with examples of how to use the Get-Date cmdlet.  Cool, huh?  What’s that you say?  Too many cmdlets to remember? Not a problem, here’s a new one: NEW-ALIAS.  This particular cmdlet is for us “memory challenged” admins.  Why type Get-Date when all I might be able to type is ‘gd’?  How does it work?  Let me show you:

That’s it!  Now instead of typing Get-Date, you can type gd and it will give you the current date.  Now for the bad news:  It’s only good for this PowerShell session; so as soon as you type EXIT or close the command prompt, your new alias of ‘gd’ will get forgotten.  Don’t worry, I’ll teach how to make it persistent in Part II of this Primer.

Coming Up Next

In Part II I will show you how to make aliases you create persistent as well as going a little deeper into what you can do with Aliases.  I will also start showing you the specific cmdlets used in SharePoint administration.