April 2008 - Posts

• Scripting the "Connect to Outlook" function

  You've got to love the "Actions, Connect to Outlook" function in SharePoint lists... Handy for offline viewing of data, nicer GUI for detail entry, etc.  Wouldn't it be nice to automate the connection of these things for a team or a project, or even a division or company? You can force these connections via script...  They are URL based using the "stssync://" protocol, which depends on the Office WSS services, a shared component of the desktop Office Suite.  You can find the specific call to connect a library to Outlook (much easier to let SharePoint format it that create from scratch) on any of the AllItems.aspx default list pages for a library or list that is "Outlook Friendly", including Tasks, Calendars, and Document Libraries.   View your page source (on an IE browser, as this is not available in other browsers) and looking for the following: <ie:menuitem id="zz23_OfflineButton" There is a lot more to this element, which is jammed on a very long line containing about 6 of these <ie:menuitem> elements.  Specifically out of this element you want to get the "onMenuClick" action, which is a javascript call to "ExportHailStorm".  You will need a copy of this function in your script as well, as this is the function that creates the stssync call.  It is located in the init.js file, located in 12\templates\layouts\1033 folder (for US versions)... The call to ExportHailStorm should look something like the code below, although I've added line breaks to make it readable.  ExportHailStorm(    'documents',    'http:\u002f\u002fsharepoint.company.com\u002fteam\u002fsitename\u002fsandbox',    '{ac5b6eaf-744a-4f73-a2e1-6e35b81f109e}',    'Sandbox',    'Test Files',    '\u002fteam\u002fsitename\u002fsandbox\u002fTest\u002520Files',    '','\u002fteam\u002fsitename\u002fsandbox\u002fTest Files');" You can use these parameters with the MS code in init.js for ExportHailStorm to make your own script with multiple connections for Outlook.  Each call to ExportHailStorm ends in a window.location.href call to the newly created link, which for a document library will look something like this: stssync://sts/?ver=1.1&type=documents&cmd=add-folder&base-url=http:\u002f\u002fsharepoint.company.com\u002fteam\u002fsitename\u002fsandbox&list-url=\u002fteam\u002fsitename\u002fsandbox\u002fTest\u002520Files&guid={ac5b6eaf-744a-4f73-a2e1-6e35b81f109e}&list-name=Test\u520Files&site-name=Sandbox These strings can be captured and put in to a simple vbscript or powershell script or even a bat file (run iexplore.exe <url>) and executed in a post setup command, a login script, or embedded in a web page on the intranet (ie, click here to connect standard outlook folders)... Posted Apr 15 2008, 10:47 AM by josef.nielsen with 4 comment(s) Filed under: MOSS, JavaScript, Outlook

• MSCS Watcher released

  For a few years now I have been making due with a simple notification system for MSCS fail-over clusters that implemented either a script, or later, an application that started as the last resource in the cluster to send an email letting me know the cluster group is online.  The biggest problem with this is that it doesn't let you know when you have unrecoverable failures.  It also is a pull-type polling device, on;y firing at intervals or when it starts up. I decided to fix this.  There currently is not much (if anything) that allows Cluster notification for the MS platforms in the OpenSource arena, so I jumped in a started a simple, yet useful project to make just that.  The end result is the MSCS Watcher.  It is a .Net 2.0 OpenSource project that utilizes the MSCluster WMI objects, specifically the EventResourceStateChange object.  I also used the Cluster Automation API to grab the current state of the cluster for reporting in the SMTP notifications.  This is the first cut at a push-style cluster monitor for me, a complete re-write of the previous MSCSWatcher I had made for personal use.  The pervious version also included SQL tables for historical and current state data. I've removed those from this version to simplify things, but I'm thinking of taking another cut at it in the future and putting it back in. Originally I was trying to write an event handler for the events raised from the API for ClusSrv, but this involved writing a Wrapper for C++ events, and I just didn't have the time to get in to that right now...  I ended up using a ManagementEventWatcher to grab the WMI events thrown by the cluster service.  My first thoughts for the actual notification was to allow it to fire an executable, to help try it in to other monitoring tools.  I decided to discard that idea when I realized it really didn't do me much immediate good.  Instead, I decided to have it simply fire off an SMTP message.  That stuck with my goal of keeping it simple. The basic functionality of this thing is that it runs as a service (I recommend clustering it on all nodes in your cluster) and waits around for any of the resources in the cluster to change their state. (ie online to failed, offline to onlinepending, etc.).  When a state change event is detected, the service records the change and does a scan of the cluster group that holds that resource.  It then does a little logic to avoid sending extra messages and if it determines the circumstances are right, it sends a summery of the cluster group that owns the resource that triggered the event. I decided that it is such a pain that there really isn't much out there either in the form of OpenSource utilities for Clusters or sample code to work with them that I would just give the whole thing away... So it is out on CodePlex now... If you use MS Clustering and don't know when your cluster fails over, go grab a copy and try it out :) http://www.codeplex.com/mscswatcher Posted Apr 10 2008, 08:16 AM by josef.nielsen with 1 comment(s) Filed under: MSCS, C#, Windows Server 2003, CodePlex