HttpCode

Windows 7 contains a really nice tool called the Problem Steps Recorder:

It can be found via the Windows 7 start menu by typing ‘problem step’

Once it’s running you get the following UI:

From here you can record all the clicks and keystrokes that your undertaking, you can even add comments to parts of your display. It finally saves the file as a zip file, which contains a .mht file that can be viewed in your browser. This output file will list things like version numbers of applications running as well as a range of screenshots of each major activity recorded.

Now this is all well and good for sorting your mum’s computer problems, but as an IT pro who has had to document some awfully boring processes, I really think this tool will help me the next time I need to document the install of some software, or some mundane configuration change.

I’ve been working on a project that involves implementing a blogging system inside SharePoint, the out of the box SharePoint blogging system was unsuitable and the Community Kit for SharePoint didn’t solve our issues.

So the system we developed was lightly based on the open source .NET Blog Engine which includes comprehensive support for the MetaWebBlog API. This API allows a interaction with a blogging system so that blog posts can be added, deleted and updated, but it also provides provisions for managing things like categories and comments.

The main motivation for supporting the MetaWebBlog API is Windows Live Writer (WLW) this great tool really makes publishing to a blog a simple task. So I happily added the MetaWebBlog API and quickly found that windows live writer doesn’t support windows authentication. WLW supports a nice feature called Really Simple Discovery (RSD) where it can just be pointed to a blog’s home page and it can get all the configuration needs. By not supporting windows authentication we lost the auto discovery features.

So I could still enable anonymous access to the MetaWebBlog.axd and wlwriter.xml (a file that tells WLW what capabilities your blog has), so now with some manual steps in WLW I could select the MetaWebBlog API and give it the url to use. My next problem was that my blogging system was all based around windows authentication. Every user has a blog that is based around their network credentials, I needed my metawebblog API implementation to validate the user to the windows network:

With the following P/Invoke definitions:

[DllImport("advapi32.dll", SetLastError = true)]
public static extern bool LogonUser(String lpszUsername, String lpszDomain, String lpszPassword,
 int dwLogonType, int dwLogonProvider, ref IntPtr phToken);                

[DllImport("kernel32.dll", CharSet = CharSet.Auto)]
public extern static bool CloseHandle(IntPtr handle);

[DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)]
public extern static bool DuplicateToken(IntPtr ExistingTokenHandle,
 int SECURITY_IMPERSONATION_LEVEL, ref IntPtr DuplicateTokenHandle); 

Now in all of my metawebblog API calls I could use a method like:

                string username = string.Empty;
                string password = input.Password;
                string domain = string.Empty;

                if (input.UserName.Contains(\\))
                {
                    string[] usernameParts = input.UserName.Split('\\');
                    if (usernameParts.Length > 1)
                    {
                        domain = usernameParts[0];
                        username = usernameParts[1];
                    }
                }
                else
                {
                    username = input.UserName;
                }

                IntPtr tokenHandle = IntPtr.Zero;

                bool returnValue = LogonUser(username, domain, password,3, 0, ref tokenHandle);

                if (returnValue == false)
                {
                    //error not a valid user .. return
                    throw new MetaWeblogException("11", "User authentication failed");
                }
                
                    if (tokenHandle != IntPtr.Zero)
                        CloseHandle(tokenHandle);

This code will return an invalid authentication message to WLW if the user doesn’t provide the correct domain, username and password (you could easily remove the need for a domain, I needed to keep it).

I’d like to say that its all good but really end users won’t go to the effort of following steps to configure WLW, the RSD is a killer feature in making web blogs accessible to end users. Fingers crossed that WLW will support windows authentication in a future version.

We’ve all probably worked on projects in the last 5 years or so that have involved reworking applications that were once built in MS access, in my case it was an access system that stored important safety testing information that was captured in an engineering workshop. It was originally designed and built by a mechanical engineer, who didn’t know much about database design.

The system was redeveloped for a number of reasons including:

• The data couldn’t be shared, it was locked away on a PC in the workshop, no analysis of the data could be performed.
• It didn’t scale well, only one user at a time could access it.

There are lots of other reasons why MS access shouldn’t be used for this type of information, but my point was that Access is a pretty poor tool for critical business information because it was difficult for the business to access this information. I think most people would share this view.

Lets compare a couple of scenarios with SharePoint as the tool, so all the information would be stored in a list:

• The data can be shared by webservices and RSS, with effort.
• It can scale, multiple users can access it at the same time.

But is the business data in a SharePoint list really easier to work with?

Can it:

• Be used in SQL Server analysis cube?
• Easily used in Reporting Services?
• Joined with other business data to see correlations?
• Perform complex real world queries?
• Do you really want to model your business data based on the limitations of SharePoint?

The answer is no.

I still think that business data needs to live in a system designed for business data, i.e. A database: SQL Server.

From here it can be queried, joined and more importantly shared, whether that be back into SharePoint or any other tool that supports a database (Reporting Services, Performance Point, Analysis Services etc).

So now that brings me back to my comparison with MS Access, we are now doing lots of work moving systems away from MS Access, will we be doing the same thing in 5 years time, moving our SharePoint lists away from SharePoint?

I think SharePoint lists have their place, no question, but not for line of business data. Keep the SP lists for trivial data that is not important to the overall operation of your business.

With the upcoming SharePoint conference releasing information about SharePoint 2010, it won’t be too long before everyone will be looking at the product. Interestingly SharePoint 2010 is 64 bit only, this will have an impact on developers using Virtual PC 2007, which only supports 32 bit guest OS’s.

However windows 7 and Server 2008 R2 supports boot to VHD, this provides the ability to create a single VHD file that can booted. Once you’ve booted up the VHD your computer has access to all of it’s CPU cores, which is a major win. I’ve read that the performance hit of virtualising the file system to write to the VHD is around 5%, so it’s barely noticeable. Most importantly you can boot into a 64 bit OS where SharePoint 2010 can be installed.

To recap, the advantages of boot to VHD:

• Can run 64 bit machines
• Access to all CPU cores
• Still keep portability by way of VHD files

Disadvantages

• Can’t multitask with the primary OS, the VHD OS is the primary OS
• Need to upgrade to windows 7 or server 2008 R2 (Not really a disadvantage, but might be an issue in corporate environments)