Ferrara Data Consulting | Company Blog

Part 1 Part 2

In Part 1 of this article I compared and contrasted the various methods that we could use for our Sharepoint update log application. I’ve chosen the custom aspx site/SQL table method as it is the most effective solution for what I currently need. I don’t intend to design a full-fledged application with reporting features, logins, AJAX menus(well.. maybe a little AJAX would be cool!), etc. I need a custom site that is independent of Sharepoint, so developers/admins can log their updates to the database. If Sharepoint breaks, then we should be able to access this data as it might help us determine the point of failure. Simple and effective.

My aspx site is uber-simple to the point to where you might question why I even spent time writing this article. Well, I’m glad you’re that concerned about my free time! I’m writing this, because I see a lot of IT shops without something like this. Keeping an update log for live servers should be a non-negotiable in your environment. I hope that this example will either offer you a solution that you can use immediately or provide you with a catalyst to design your own solution based on your needs. You don’t have to be a VB.NET guru to get this done. For this article, I’ll show you some screenshots, so you can laugh at see how simple this is.

• As you can see I have a few drop down boxes and text boxes that match the table layout from the previous article. I’m not sure if I can prove it, but I’m sure there’s a developer somewhere named John Madden.

• I’ve added the necessary information to the form, and I am ready to submit. The change log text box is basically just a multi-purpose field for people who want to link to the actual change log or other document explaining what this update is for. This example links to the Microsoft page pertaining to the KB article. This could also be used for relative locations on the local network.

• Click submit, and the data is added to the database table! Praise be to ASPX.

I hope that you can now see how easy this is to do, but also how effective it is for keeping an accurate log of what you’re updating on the servers. This solution would probably suit small to medium-sized operations the best, as the big boys generally have enterprise software to handle this.

Another plus about this solution is that you can use Sharepoint as the front-end by using the BDC or Bamboo’s MashPoint, host the site by itself via IIS, or do both and connect to it with a web part. Part 3 will cover these options and conclude the series.

The amazingly kind and helpful folks over at Bamboo Solutions, a leading SharePoint web part/solutions developer, has allowed me to write guest articles on their Bamboo Team Blog. The subject of this post, Sharepoint and Search Server 2008, is my first post there.

Please read the full post here.

While you’re there, I strongly suggest spending some extra time browsing. Bamboo Nation, their community site, is a hidden treasure in the SharePoint community. They have a very active team of content writers that will keep you going back for more.

A frequent request from end-users is the ability to remove the “title” column from Sharepoint lists and document libraries. You can rename this column to something else, but I do not recommend this for various reasons. “Title” is a reserved Sharepoint word and renaming it has been known to break things. Generally this only occurs if you change it in the Site Content Type Gallery, but I tend to err on the side of caution here. You can read about that particular limitation here.

But you can hide the title column from the default content types already built in to Sharepoint with a few easy steps. I’ve posted ample screenshots below for the visually stimulated!

Step 1. Navigate to the desired list that needs to be configured. I am starting with an out-of-the-box Sharepoint task list that has not been configured in any way. You can do the same or start with a custom list.

Step 2. Click on Settings and then List Settings. Once on the settings page for your list, click on the advanced settings link as shown below.

Step 3. The advanced settings page is not all that advanced as there are some common settings here, but you will need to set “Allow management of content types” to yes before proceeding. Click OK to continue.

Step 4. You should see the Content Types section now which will allow you to edit all settings pertaining to the content type that we want to edit. Although not in the scope of this article, this is also where you can create/edit workflows pertaining to your content types. Click on the content type name, Tasks in my case, to get to the next step.

Step 5. Select the Title column from the column list.

Step 6. Change the status of this column to “Hidden (Will not appear in forms)” and click OK.

Step 7 (Best Practice Option). When you are finished managing your content type, then you might want to go back into the advanced settings page and disallow the management of content types. Either way, your configurations will be saved, but this prevents the conspiracy theorist admins out there from blaming inadvertent changes on “the other IT guy”. I’ve added another caveat of this step below in the update section.

After these steps have been completed, then you will no longer see the Title column when adding a new item on this list.

As you can see, altering the default content type is not very difficult, but it can enhance usability on your lists. In the future, I will discuss the benefits of creating your own content types in the Site Content Type Gallery, and why it can make your life a lot easier when creating custom lists for yours users.

Update 2008-09-05: I failed to mention in my original post that you will not be able to manage the order of your columns on the list settings page again until you switch “Allow management of content types” back to No. When the management of content types if enabled, you can then reorder the columns for each specific content type. You may or may not want this to be your standard setup, so my best practice here would be to turn this feature back off when you are finished managing the content type.

Part 1 Part 2

It’s not everyday that you find a company or IT department that keeps a structured and updated “update log” for their systems, let alone Sharepoint. Updating your software is as easy as clicking a few buttons and trusting that everything will work as advertised. And for the most part, application updates really do what they are supposed to without causing outages. With communities, blogs and wikis for just about every application in existence, developers find it much easier to distribute test builds to the masses and receive responses rather quickly. This translates to quicker bug fixes and an overall better experience for end-users. But this can also lead to an ultra-trusting mentality when it comes to updating your software with major upgrades and/or patches. It only takes one patch to create hours of work for you and your team to get the system back online when incompatibilities rear their ugly heads.

This three part article will aim to give you my thoughts for an effective update log for your Sharepoint servers.

NOTE: I’ve written this article with respect to Sharepoint specifically. It is part of a larger concept that could be incorporated into all LOB systems.

The first thing that we need to do is figure out where we should store our data. Depending on your needs and organizational size this may be a very simple setup, but it still helps to think it through first.

The table below summarizes a few pros and cons for 4 possible scenarios.

This is a pretty self-explanatory table, but I want to touch on one of these a little bit deeper. When thinking of an update log for Sharepoint servers, the first thing that comes to mind would be an easy to maintain Sharepoint list. It is by far the quickest way to get data in a nice format that others can read/edit. But this option does not accomplish enough independence from the platform itself. If your Sharepoint farm is down, then you’ve negated the update log completely. So although Sharepoint may be an option for you (if you aren’t worried about a severe failure), I would recommend not storing your data in a native Sharepoint list.

With that said, I’ve chosen to store my data in a custom table on MS SQL Server 2005. The below query will get you started with a simple update log table to store your data. You can change the structure below to match your naming system, but make sure that you are not adding this table to any of your existing Sharepoint content databases. It can be tempting to store this data in your default Sharepoint content database for ease of use, but that comes along with a higher security/corruption risk. And although I haven’t tried this long enough to see if it will break something in Sharepoint (like a restore process), play it safe and create a separate database. I’ve called mine “admin” to keep things simple.

USE [admin]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[sp_updates](
[id] [int] IDENTITY(1,1) NOT NULL,
[developer] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the developer of the update
[application] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the application affected
[type] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the type of update applied
[number] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the update number or KB number for Microsoft updates
[change_log] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
–Refers to a UNC path or HTML link to a change log file
[date] [datetime] NOT NULL
) ON [PRIMARY]

Stay tuned for the next article where I will show you a small custom aspx site that will access this table. Furthermore, in the third and final article on this subject, I will display the best of both worlds. It will cover the usage of Sharepoint as a front-end display for your update log, while still maintaining a level of data independence.

Your feedback is always welcome!

Today we’ve joined forces with Bamboo Solutions to better provide custom Sharepoint web parts and solution accelerators to our clients. If you haven’t heard of Bamboo Solutions, then head over to their site to learn about their large product offering for Sharepoint. We are currently offering free support on all Bamboo products purchased through us! Contact us today for a free quote on custom WSS 3.0 or MOSS 2007 implementations, now featuring Bamboo Solutions addons.