SharePoint Bit Me

A blog about the care and feeding of SharePoint

A Quick PowerShell Tip (redirecting the output of a PowerShell script)

If you have been to this blog before you may have seen my SharePoint 2013 preupgradecheck script. One thing that always bothered me about that script was that I had to ask the user to redirect the output when they ran the script by using the out-file cmdlet, like this:

Open the SharePoint 2010 Management Shell and type:
c:\[directory where you placed the script]\InfoScript2010.ps1 | Out-File -width 200 c:\InfoOutput.txt

I kept thinking there had to be a better way to redirect the output from within the script itself, but I never really took the time to come up with a solution until recently. After sitting and really thinking it over for a few minutes instead of just complaining I found a simple answer that I thought I would share here, even though it isn’t really about SharePoint.

A nice  feature in PowerShell is the function, simply put simply, a function is just a block of code that you have wrapped up so you can use it later in your script. For example:

function sayHello
{
write-output "Hello, how is your day?"
}

After creating this function in your script you can call it at any time by just using sayHello as a command and everything within the  brackets { } will execute. This is great for pieces of code that repeat, or that need to be run under different conditions, but it turns out it is also an easy way to redirect output. For example, if you have the function above in your code you can redirect the output to a file very simply.

sayHello|Out-File c:\hello.txt

So with my preupgrade check as an example, I could just enclose the entire script inside a function called outRedirect and then pipe that into the file I want.

function outRedirect
{
(the entire script found here)
}

outRedirect|Out-File -width 200 c:\InfoOutput.txt

As with most of my PowerShell advice, this isn’t exactly rocket science, but I like to share and I hope it is useful to you.

December 31, 2013 PowerShell

SQL and SharePoint

I have mentioned in previous blog entries that SQL is a pretty important part of SharePoint performance and stability. This is important because there are a few things about adjusting SQL for SharePoint that go counter to what I like to call “DBA Lore”. Database Administrators are professional specialists who have a spent a lot of time creating an unwritten set of recommendations for keeping servers running at peak efficiency. Much like wizards DBAs, are subtle and quick to anger when you try and meddle with their servers. SharePoint can be a little frustrating for these highly trained professionals because it requires a little special treatment and may break some of those unwritten rules.So let’s talk about some of those special needs.

SharePoint should have its own SQL server instance.

Most DBAs don’t argue against this in theory,  but in practice they don’t have a budget any larger than the rest of us. Economic concerns have made it a common practice to put as many databases as possible on a single instance, because each instance has a certain amount of overhead.Enter reason number one why SharePoint is a special case; it’s called the “Maxium Degree of Parallelism” or the MAXDOP option.The MAXDOP setting limits the number of processors that are used for the execution of a query with a parallel execution plan. In a system like SharePoint that tends to have a large number of queries, relative to the number of processors, running at the same time, a low MAXDOP setting is desirable. Essentially the value of 1 suppresses parallel plan generation making each query stay on the processor it starts with.  This SQL setting has been recommended with SharePoint for sometime now. In SharePoint 2013 it has gone from being a recommendation to a requirement. The MAXDOP setting can have a very negative impact on database queries that assume they will be allowed to run in parallel, so if they are hosted on the same instance as SharePoint performance will suffer.    If the MAXDOP setting isn’t a good reason for isolating SharePoint databases, then consider the fact that a SharePoint Server 2013 installation by default (basically just clicking through all the wizard options) creates 20 databases. These databases can be quite demanding on a server, and if they have to share with unrelated SQL data for resources in the same instance everything suffers.

SharePoint Databases Don’t Want Your Help

The rules are a little slippery in a few cases, but here is the general advice: Don’t run any SQL commands that query or manipulate data directly against SharePoint databases. That’s it. Don’t reorg, don’t reindex, don’t SHRINK DB’s, don’t do all the stuff normally associated with DB maintenance. Backups and DB checks are as far as you should go.

This goes double for changing the default permissions of the SQL service and admin accounts. Don’t take the db_creator and Security admin roles away from the account used to install SharePoint, don’t make the DBA’s account owner of all the databases and take the service accounts out of db_owner. DB checks and back it up, then walk away.

Finally, if your DBA’s have questions about the db types in SharePoint, how fast they grow, what recovery model they should use, all that stuff, then direct them to this link http://technet.microsoft.com/en-us/library/cc678868.aspx . This technet article is full of details they will hopefully find useful.

Remember SQL does all the hard work so SharePoint can make everything else look easy. It is a big part of your SharePoint equation so treat it right.

 

November 19, 2013 SharePoint, SQL

The Most Important PowerShell Snippet You Will See Today

Don’t worry about what it does, just cut and paste it.

New-Item -ItemType directory -Path $home\Documents\WindowsPowerShell
Write-Output "Start-Transcript" | Out-File $PROFILE

Just kidding! This is a little snippet of PowerShell code that will set it up so that every time you launch PowerShell it will automatically create a transcript of the session. That way if something goes wrong or unexpectedly right you can look at the transcript later. It also means if a co-worker goes in and breaks stuff with PowerShell without telling you, there is a transcript of what they did.

Here is what it does:

New-Item -ItemType directory -Path $home\Documents\WindowsPowerShell just creates a new directory in the users Documents folder called WindowsPowerShell.

Write-Output "Start-Transcript" | Out-File $PROFILE just writes the cmdlet Start-Transcript into a file named $PROFILE. PowerShell is hard wired to process this $PROFILE and run whatever commands are in it as a starts.

So that is it, easy but very useful.

October 31, 2013 PowerShell

SQL Tuning for SharePoint 2013

Special thanks to John Denman (@john_denman) for this list of links containing SQL Tuning tips for SharePoint 2013. Just in time for me to pass it on to my SharePoint 2013 Class.

October 11, 2013 SQL

SharePoint 2010 – 2013 preupgradecheck

For all of you who are considering an upgrade to SharePoint 2013 you may have noticed one feature that is missing from SharePoint 2010, the pre-upgrade check. In SharePoint 2007 (post service pack 2) there was an stsadm.exe -o preupgradecheck option that gave you information about possible issues upgrading your 2007 farm to 2010. In SharePoint 2010 that option is no longer available and instead the recommended upgrade tests are Test-SPContentdatabase , Test-SPSite , and Request-SPUpgradeEvaluationSite . These three PowerShell cmdlets can give you a lot of useful information, and they definitely tell you many of the things you need to know to successfully upgrade your 2010 farm to SharePoint 2013. These commands all come with one big problem, to use the above commands you have to have a SharePoint 2013 farm in which to run those commands. If you are just wondering about the upgrade to SharePoint 2013, but you aren’t yet serious enough to have installed a server you were out of options…until now!

To make some attempt at correcting this terrible injustice I have written a fairly basic PowerShell script that can give you some of the same information the old “preupgradecheck” option gave you. Information like what your farm’s build number is, what templates you have and what web uses which template, database sizes, solutions installed in the farm, etc. If you felt like it you would be able to get most of this information by digging around in Central Administration, SQL Management studio,  the SharePoint settings pages, or SharePoint designer, but this script may save you a little time. The script won’t tell you anything specific about the problems you may have upgrading to 2013, it just gives you all the information in one place to use as a reference. I hope you find it to useful, and you can find it HERE.

 

No Warranty Expressed or Implied. Use with caution (that applies to all PowerShell written by some random person on the internet). Do not drive or operate heavy equipment for at least 4 hours after using PowerShell. Side effects may include bleeding from the eyes (my code is not pretty), heart palpitations and severe migraine headache. Good luck.

August 18, 2013 PowerShell, SharePoint, Tools

Stupid PowerShell snippet of the week – List Installed Windows Updates.

OK, so this isn’t strictly SharePoint, but I have been bitten a few times lately by Microsoft patches, particularly those of the .NET variety. In both cases there were 2 problems that came up.

  1. Looking through a list of updates by the KBXXXXXXXX number is difficult in the Windows Update GUI
  2. There are a lot of updates, which makes it difficult to compare what is installed on two different machines.

My answer? It  isn’t exactly a quantum leap in PowerShell technology, but it is a script to list the installed Windows updates and the output can be easily directed to a text file so you can search it easily in notepad or compare it to the output from another machine.

$wu = new-object -com "Microsoft.Update.Searcher"
$updatecount = $wu.GetTotalHistoryCount()
$wu.QueryHistory(0,$updatecount)|select title

 

( add |out-file updatelist.txt  right after select title to dump all of the output into a text file for easy comparison.)

I hope this is a helpful snippet in your time of troubleshooting need!

 

 

 

May 20, 2013 HowTo, OffTopic, PowerShell

Help! SharePoint 2013.

Lots of stuff is going on with SharePoint 2013. Not much has been going on with my blog. I need some topics people. My specialty is Infrastructure, Install, and technical issues around getting SharePoint up and running, but if I get a clear idea of what people want help with I will stretch to other topics. So help a guy out, let me know what information you are really dying to see content about.

February 21, 2013 SharePoint, SQL, SSL, SSRS, Tools

SharePoint Saturday Michigan Presentation

Thanks to everyone who attended SharePoint Saturday Michigan, it was a great event with a great crowd and I hope I get to attend again next year. For those who attended my session I apologize for the missing content. I have added the slide about Service Packs back in and made some contents in the notes, since it doesn’t make a lot of sense if you just read it without me babbling on about each bullet point. For anyone interested in the rest of the slides without my babbling you can find them here.

October 3, 2012 Uncategorized

I just got my first article on Technet Magazine published!

http://technet.microsoft.com/en-us/magazine/jj649371.aspx

 

September 25, 2012 Events

Quit Your Job!

SharePoint 2013 Preview has a lot of interesting and improved features and I am really interested to see how they will be used as 2013 starts to gain traction in the market. That being said, most SharePoint 2013 installations aren’t going to be fresh environments, they are going to be upgraded from SharePoint 2010. I look at SharePoint farms everyday, and frankly a lot of them aren’t ready for that upgrade. I am not blind to the fact that, as a consultant, I wouldn’t be looking at most of these farms if there weren’t some sort of problem, but there is one very common issue that I see over and over that could be solved simply.

Here is the issue. No one knows anything about the farm. Why are there 3 different names in the AAM for this web application? What is www.madeupaname.com:13345 for? Why are 3 web applications attached to the same content database, using the same type of authentication? No one knows, or no one remembers, and in some cases, no one cares. What is the password to the farm account? What is the password to the account that  has farm/site collection/local machine and SQL administrator permissions? Which of the 37 farm solutions installed in the farm are actually used? Where are the wsp files and license codes for those purchased solutions?

So here is the “Quit Your Job!” part of the post. Imagine you just won the lottery. You are about to quit and move to your private island, but first you want to be nice to the person who has to take your place. Write all the accounts and passwords down, put them in a sealed envelope/password safe program and give them to your boss for safe keeping. Put a text file named info.txt on the root of the C: drive of the machine that has Central administration on it. Write down all the things that you know about the farm. All the little settings, all the reasons for unusual setups, anything that that is out of the ordinary about your farm. No passwords, no in-depth information about your network or firewall, just why and when little changes were made. In this little thought exercise, the notes are for the person taking your place, but in reality if you keep that little text file up to date the notes will be for you a year or two from now when you can’t remember why you created a web application, or host header. This one little text file will save you time, money, and possibly a few therapy sessions.

Upgrading SharePoint to 2013 (or 2010, or 2007) is a lot easier when you know what databases need to be available in the new farm and what settings are needed to make it work correctly in your environment. Right now it may look and sound like SharePoint 2013 is the hard part of the upgrade, but the new product is almost never the problem. It is the accumulation of truly necessary but unsupported customizations, day to day workarounds, and forgetfulness, that make the upgrade hard. Information is your best tool for working around a lot of obstacles caused by that accumulation.

So quit your job right now! Write down everything your replacement needs to know (or everything you need to remember in a year). Sure, you have a better chance of being hit by lightning than winning that lottery, but those notes might come in handy someday.

August 17, 2012 SharePoint, Tools, WhyTo