A lot of administration work can be done from the command line using STSADM. Adding and retracting solutions, resetting IIS, interfacing with GACUTIL, adding users, creating sites and webs, and the list goes on and on and on… after a while, you may want to keep a record of the operations that you had performed. This is very helpful in keeping a server log together, so you can always go back and trace what has been done.

By using the following command: DOSKEY /history, you can do just that. Looking to find out what DOSKEY is? Check Wikipedia of course 🙂 But, if you don’t want to go elsewhere to find out, we’ll just quote Wikipedia, they say it better than I can.

“DOSKey is a utility for MS-DOS and Microsoft Windows that adds command history, macro functionality, and improved editing features to the command line interpreters COMMAND.COM and cmd.exe. It was included as a TSR program with MS-DOS and PC-DOS versions 5 and later, and with Microsoft’s Windows 95/98/Me.”

If you’d like to save that off to a file? Also not a problem, just run: DOSKEY /history c:\STSADM.042010.txt and you’re ready to go. Your command history will be backed up in C:\STSADM.042010.txt.

This is just a quick reference post. I often find myself looking for the GUID of the Title column, which is a default column on all lists. The GUID for this is the same in WSS and MOSS, as it is part of the Item content type, and will always have this GUID, at least as far as I know, in WSS 3.0 and MOSS 2007. So, here it is!

{fa564e0f-0c70-4ab9-b863-0177e6ddd247}

I received a comment on the GraceHunt.SharePoint.Features.CompleteTask project on CodePlex yesterday, and while responding, I thought I would also put together a post on locating the List Template ID for a list within the SharePoint UI.

Quick note – you will need to have the permissions to create new lists on the site to be able to do this.

First, go to Site Actions > Create

Next, hover over the the list template that you would like to know the internal List Template ID for, as shown below. For example, the Project Tracking – Project Tasks List, which is part of the IT Team Workspace template, available within Microsoft’s “Fab 40” Application Templates.

Next, look down in the status bar of your browser, or, click on the link, you will see the last variable in the query string for that link is named ListTemplate, and that will display the List Template ID for that list type.

A few weeks back, I had written a quick post about BLOB (Binary Large OBject) storage in SharePoint. Well, one of our partners, AvePoint, released yet another of their tools for FREE, the DocAve Extender, for SharePoint 2007 and 2010, to aid in this matter.

Straight from their website – here is some more information on the groundbreaking release of this tool, for free.

“Databases like SQL Server are designed to handle relational data of relatively small size (typically less than 1MB). However, when it comes to larger, non-relational data streams, known as Binary Large Objects (or BLOBs), databases like SQL are not optimal. This is because managing BLOB I/O calls takes up substantial SQL CPU and memory resources.

Since more than 95% of the data a typical organization uploads into SharePoint are BLOBS, SharePoint’s SQL resources become quite overburdened, and have less capacity to perform transactional data operations and queries.

To avoid this, organizations have a few options. The first option is to spend money on additional SQL Server resources. But SQL Server licensing is relatively expensive when compared to file-based storage, so this is not the most cost-effective route.

The second, more cost-efficient option is to extend this BLOB content directly to file-based storage, while providing unfettered user access to the BLOB content via SharePoint.  To do this, administrators can either:

• Write custom code that leverages Microsoft’s APIs to create their own BLOB management functionality
• Buy some expensive third party tool
• Use AvePoint’s FREE DocAve Extender.

With DocAve Extender, BLOBs are never stored on the SQL Server database, meaning SharePoint can perform optimally, your SQL Server resources can be utilized efficiently, and your database costs can be kept to an absolute minimum.”

The utility allows you to literally have terabytes of data within a single content database. It can be encrypted and compressed as well for secure and trimmed storage, and stored on file servers, NAS, SAN, or even Cloud storage mediums.

So if you are looking to offload large file storage in SharePoint from your SQL server – look no further. http://www.avepoint.com/sharepoint-storage-extender-docave/.

A good friend of mine, Mark Rackley, posed a question to me yesterday…

Which was a great question, and one that throughout all of the times I have spoken at various events and user groups on Custom Actions, I had never heard asked. So, I thought I would post a blog on this, and answer the question for others as well. Thanks for the ? (“question, Mark”)

Well, why don’t we see what we can do – I’ll take you through the trial and error process, to see if we can make this work.

So, let’s fire up Visual Studio, and get started, and let’s create a new blank WSP Builder Project (as I know Mark is a big fan of STSDEV)

Lets build out our folder structure, and add in our feature.xml file, as well as our element manifest

In our Feature file, let’s scope this out to the Site Collection, and fill in some of the other details…

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <Feature xmlns="http://schemas.microsoft.com/sharepoint/" 

   3:          Id="{842E1000-139E-4e3e-A747-F6E01B2A5AAE}" 

   4:          Title="MarksCustomAction" 

   5:          Description="Mark's Custom Action" 

   6:          Scope="Site" 

   7:          Version="1.0.0.0" 

   8:          Hidden="false" 

   9:          ImageUrl="GraceHunt\Grace-Hunt.gif">

  10:  <ElementManifests>

  11:    <ElementManifest Location="manifest.xml" />

  12:  </ElementManifests>

  13: </Feature>

  14:  

Now, to populate our ElementManifest, which will contain our CustomAction Element, let’s refer to the CustomAction Element section of the Windows SharePoint Services 3.0 SDK.

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

   3:   <CustomAction

   4:       Id="MarksCustomAction"

   5:       Location="EditControlBlock"

   6:       Title="Grace-Hunt Website"

   7:       RegistrationType="List"

   8:       Sequence="12345">

   9:     <UrlAction Url="http://www.grace-hunt.com" />

  10:   </CustomAction>

  11: </Elements>

  12:  

Now, we know, especially if you’ve been to any of my sessions on Custom Actions, that the only thing you REALLY need in here is the Title attribute, but, we’ll add an Id, Location  – the Edit Control Block, a Title, set the RegistrationType to List, and, let’s give it a sequence number of 12345, and set the UrlAction to be http://www.grace-hunt.com.

Now, let’s deploy, and see what happens…

Using STSADM, let’s add the solution to our Farm. This will also give us a sanity check, to make sure that we have no errors in our feature. Otherwise, it would kinda yell at us…

Ok, that went well. Now, let’s deploy the solution…

I’ll create a Custom List, Document Library, Announcements List, and a Task List.

And, then activate the feature…

And now, let’s go check the EditControlBlock of our lists…

Checking Tasks… nope.

How about our Custom list…. nope. Not looking good at this point…

And also checking the others…nothing. Well, this didn’t pan out too well. Let’s try something different. Since all content types inherit from the System content type, whose ID is 0x, let’s see if we map to that content type, if we have some success… so, let’s update our ElementManifest to the following…

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

   3:   <CustomAction

   4:       Id="MarksCustomAction"

   5:       Location="EditControlBlock"

   6:       Title="Grace-Hunt Website"

   7:       RegistrationType="ContentType"

   8:       RegistrationId="0x"

   9:       Sequence="12345">

  10:     <UrlAction Url="http://www.grace-hunt.com" />

  11:   </CustomAction>

  12: </Elements>

  13:  

and re-deploy, and see what happens. Let’s check our Custom List…

There it is! Let’s try our Document Library…

There as well! And our Tasks List? Bingo!

And also our Announcements List

So, as you can see, you can get a Custom Action to appear across all list types, by binding your Custom Action to the registration type of List, and  the base content type of 0x, and you can get a Custom Action to work across all list types, as all content types inherit from the System content type, 0x.

For more Custom Action resources, try this search against my blog.

I’ve been hearing a lot of chatter recently regarding BLOB (Binary Large OBject) storage in SQL. In fact, people have been talking about it many years. Thankfully, there are quotas which can be enforced, however, you still need to store BLOBs (photos, images, videos, documents – basically any attachments or files uploaded into SharePoint are BLOBs) in SharePoint, and SQL disk space can be, and is expensive.

Now, there are a lot of companies, some who are partners with Grace-Hunt, which make use of functionality within the SharePoint API to store files out of band from SQL, maintaining these BLOBs just as if they were in SQL. One of those companies, StoragePoint. They have a free tool, called BLOBulator, which is definitely geared towards their product, however, it is a great tool to peer into your SharePoint environment, and see how much space you actually can save by using an out of band BLOB storage solution such as theirs.

This is not a marketing effort – however, more of a reference point for myself to remember this tool, and share it with others who may have some use for it.