We released the fully supported toolkit twice this year. The 3.0 release contained the first version of the SPDiag tool.
We published a How-To walkthrough video with the help of Hilton Giesenow on how to use SPDiag 1.0 here: http://technet.microsoft.com/en-us/office/sharepointserver/ee221106.aspx
Then between February and August we worked on the 4.0 release of the toolkit. The 4.0 release contained a number of updates to the already released SPDiag tool as well as a new Permission Reporting solution, updates to other existing tools and a few other odds and ends. You can read more about that release here: http://blogs.msdn.com/sharepoint/archive/2009/08/27/announcing-the-fourth-release-of-the-microsoft-sharepoint-administration-toolkit.aspx
After completing the 4.0 toolkit, Hilton created some additional content for us—first an interview of Luca and I (Permissions Report and SPDiag Program Managers). You can listen to that here: http://www.themossshow.com/2009/10/looking-at-the-sharepoint-administration-toolkit-4-0-with-dan-winter-and-luca-bandinelli/
Hilton also recorded an updated How-To video for us on SPDiag, but with the second version that was in the 4.0 release. This is pending upload and should happen soon (right Hilton? :p).
It is worth noting that the SharePoint Administration Toolkit was not designed (specifically blocked in some instances) from running against SharePoint 2010. This is because of two factors. First, much of the functionality is now a part of the product. Secondly, for the functionality that is not—we are working on a SharePoint 2010 Administration Toolkit as a completely new toolkit.
I’ve never heard of ULS before, what are ULS trace logs? Why/when would I want to use ULS logs? How can I make ULS logs less complex?
These are all questions I’ve heard before. First, Unified Logging Service (ULS) trace log files are log files stored on every SharePoint server individually that provide a running audit trail showing details (including detailed error information) of events that occur on that server. They are called Unified because all Office Server products log to the same place. You don’t get a separate log file for Excel Service, etc. In most cases, checking the ULS logs can uncover important troubleshooting clues, so it is worth learning a little more about. You could start digging into technet here if you would like (our 2010 documentation on this area is not yet posted): http://msdn.microsoft.com/hi-in/library/aa979590(en-us).aspx
The reason I bring up ULS is because I showed off a new tool at the SharePoint Conference 2009 called ULSViewer. ULSViewer is a tool that was developed internally after the ULS infrastructure was built for the 2007 products. We recognized as we were building 2010 that the majority of the product group was using this tool when doing investigations, so we wanted to release it publically so that our customers could experience the same benefits that we do. The ULSViewer tool works both against SharePoint 2007 and 2010. We will release an update to the tool around the RTM timeframe of 2010 based on feedback we have gotten from you.
There is one important thing to note about ULSViewer. Unlike the SharePoint Administration Toolkit, it is not a supported tool. This means that we will not entertain hotfix requests or cases with product support. You are welcome to submit thoughts on the code gallery that we will think about for future revisions of the tool, but it is an “at your own risk” tool. That said, we feel the risk is very low J
If you haven’t seen it—check it out: http://code.msdn.microsoft.com/ULSViewer
It sounds powerful… therefore I want it. …but how do I use it?
This is not an untypical question for admins who first approach 2010 and get curious about the Management Console. Obviously there are some folks who are Windows PowerShell wizards and have been using it for years to manage Exchange Server, etc… but for the rest of us, we have Zach J. Zach has been posting a number of PowerShell introductory topics to help the rest of us catch up. If you haven’t seen it, it would be worth your time to circle back to his older posts in the PowerShell category and start playing through them. I found this to be a lot of fun and learned a number of things along the way. Don’t fear, Zach isn’t our only PowerShell documentation investment—we have a lot of PowerShell goodness coming for technet that I know you’ll enjoy, but for now—give his content a read: http://sharepoint.microsoft.com/blogs/zach/Lists/Categories/Category.aspx?Name=PowerShell
This leads us to the most exciting part (for me) of this post, the answer to the question of “but I already am comfortable with/know how to use PowerShell… what do you have for me?”. <insert dramatic pause> The answer is SPModule. SPModule is a collection of Windows PowerShell scripts for SharePoint 2010 that cover basic operations such as scripted deployment installation or creating/joining a farm. There are a number of other tasks that also are starting to surface in SPModule such as collecting all of the log files. We have a lot of plans for SPModule, but the thing to take away from it today is that the infrastructure for it is in place and we are sharing SharePoint best practices when using Windows PowerShell through these working examples. If you are playing at all in the SharePoint 2010 PowerShell space, I highly encourage you check this out: http://sharepoint.microsoft.com/blogs/zach/Lists/Posts/Post.aspx?ID=54
Thanks, and happy holidays!