Using Custom Forms for data entry with Outlook/Exchange Public Folders

An interesting learning experience today regarding the use of custom forms in Outlook.

I was attempting to customise folder in our Public Folders, for use with customer contact details. The bigger picture is that our back office user registration system, has to update a public contacts folder used by sales guys and management to track support renewals and just generally log activity with our customers.

The logical starting point for the sychronisation with the back office system, was to ensure all the fields that the users require, actually exist against contacts in the public folder. Thus began my customised Outlook forms adventure.

First tip, "you need to make sure the appropriate users have ownership rights on that public folder in order to add the new fields" - this is best achieved using the Exchange System Manager - on the Exchange server.

Then, it was down to business, creating a new form for data entry in this public folder. I started with some very minor changes, just to "spike" the whole solution to ensure it was going to work the way I expected - good move. I created a new form and published it into the Public Folder. Then, from the Tools menu I could select that form to do some design work on (Tools/Foms/Design a Form) then choose your Public Folder in the "Look In" drop down list. Select the form you just published there and open it.

Once your are accessing the form, in design mode, but selected from the one published to your public folder, the custom fields added to that folder, will be available for you to choose in the Field Selector - "User Defined Fields in Folder" selected in drop down list on top of the Field Chooser.

So, you add a few fields, publish the form back into the same public folder, then go to that public folder to try it out.

Firstly, you'll need to make sure the form is assicaited with the folder. "Right click" the folder, go to Properties, then the "Forms" tab, if the form is not showing in the list, click Manage. You should see the form in the list. Closing this form sometime seems to refresh your forms list on the properties dialog, if indeed, the form was missing in the first place. The other setting that must be made here is on the General Tab. Make sure you select your new form in the "When posting to this folder, use:" field.

Now setting this much up achieves only half the job. Any new items "posted" to this folder will make use of your new form. Any existing ones will not. Why? The answer turns out to be to do with the Message Class of existing and new messages.

New messages will automatically take on the message class associated with your new form - old messages will have the message class of the old, original form used to create them, and therefore continue to use that form, when you open them for editing.

This brings me back to another trap I fell into back at the start. When you first create your new form, (Tools/Forms/Design a Form) make sure you inherit from the appropriate type of form, in the Standard Forms Library. New items, added using your new form, will take on the class of that form, plus the name of your form - so in my case where I was using a Contacts Public Folder the message class of my new items became, IPM.Contact.AllUsers. This message class is the key to getting older/existing items in your folder to use you new form.

You can display the message class in a list view in your folder. Using the Field Chooser, find "Message Class" (in the All Post Items category) and add it to your view. You can then see the message class assigned to all items. Quickly adding a new one will show you what your form is using and you'll know what the older ones need to be changed to.

Now, changing the items seems to be easier said than done as well. At this point I must hand much of the credit over to this post on the Windows IT Pro site. This is what explained to me the importance of the Message Class and also directed me towards the tools to change it.

The tools I used turned out to be the macro in the Word Document found on the Microsoft site - here but upon reflection, would've been quite easy to write myself. Anyway, now, all items in my Public Contacts folder have the correct Message Class, and now use my newly customised form. Now it's time to go to town on customisations to that form, and also some cool new views of that folder.

That ol' chestnut - software development estimates

This old chestnut keeps rearing it';s ugly head - the customer has to know how much the job will cost, before they'll commit - the devleopers can't say until they know more about what the users want. Big design up front with "sign off" in blood is next to useless - we've all seen that - the one constant thing is "change".

There is an interesting post and related discussion related to this topic on TechRepublic - here. This is more about building schedules and developers estimates.

Recently I had to address this problem yet again. My esimating by gut feel skills are always improving. I had to quote a job for only about a month's worth of development work. I spent quite some time makung sure I understood the requirements as best I could, with input from a couple of subject matter experts and of course 4 senior users from the customer's business. Anyway time came to finalise the spec and quote for this customer. I have pushed a fairly Agile approach in that over those weeks well keep showing you progress, we'll build daily and so on, but there will only be two points in the process where delivery to the customer will be worth-while. The changes will form part of out daily build/test cycle so our feedback loop will be short but not from the customer - we have a commercial product, released quarterly so we can't very well be shipping weekly to a customer.

Anyway, after careful condieration I broke down the WBS as best I could and gave some estimates. Everyone, including the customer was happy with the time frame and related costs.

The developer, ultimately charged with doing this work, was on leave and could not be contatct. He started the work first day back, and was immediately grumpy. Probably at not being consulted and fair enough too - he was stuck with a schedule, he'd had no input into - very unfair and very "non-Agile". However after a few hours work he was making noises about how this first task is going to take a month, let alone the rest! I started to lower customer expectations around the deliver time - subtely. Three days later, he was almost finished that first task, 10 days on the estimate, the one he'd said would take weeks. Now, he quite cheerily says, "I think I'll finish this easily inside those 26 days you've quoted the customer."

This is a great example of a couple of quotes in the discussion on the TechRepublic post I linked to above, firstly, one of the best tools in relation to estimating and scheduling software development, is experience, secondly, team leads and managers tend to build a bit of fat into their estimates, developers tend to under-estimate all the tasks. I have no doubt we won't be finished as easily as our developer now thinks, but I was also unnecessarily worried with that initial concern - my experience has served me pretty well, and the fat I built in originally was about right!

ASP.Net AJAX

Lately I've been playing with the new Release Candidate for AJAX, albeit being guided by video tutorials, firstly for the CTP version, then later, for the Beta version. Anyway, thanks to a little help from the ASP.Net forums I'm starting to make some progress.

Last year I helped out a small company I worked for some time ago, with some ASP work - they have what amounts to a good proto-type for a product which they are trying to sell, and I think with some Ajaxifying - they could really take it somewhere - we'll see.

A battle of best intentions...

I love the line in this New York Times Technology article that says It is a battle of best intentions: productivity and convenience pitted against security and more than a little anxiety. - that's so true! This article is talking about the network adminsitrators security nightmare that is Web based mail accounts. It's true that sales and marketing guys just want to be as "efficient" as they can - they are not usually really that malicious - just often, incredibly ignorant to the threats and possible costs. So forwarding information (and even attachments) of to web based mail accounts seems like a good thing to do right - surely?

It's impossible to expect anyone not actively involved in the security process at a firm and the rationale behind it to accept, or even comprehend, why the so called "barriers" are put in their way - and that sort of active involvement is impossible to implement across an entire enterprise. But as IT professionals we must undertake to spread the word any chance we get - anytime.

We should also place the responsibility for the existance of these "barriers" firmly with informed business managers - by informed I mean, completly briefed on the risks and costs of lax security, and just how easily exploits can be raised. If after comprehensive training of all these managers they still want to drop their guard so to speak, and remove any of the barriers how much more can you help them? They can make an informed decision between the cost of lowering security and the benefit to be gained.

My approach is usually to say - it's not me that wants these measures in place it's your manager. What is left unsaid, is that I (or someone in IT) are the ones responsible for scaring them into accepting nothing less. That scaring is not that hard to do. Point out the risks of your department being respoinsible for a law suit against the entire company for breaching privacy laws, vs the ability for someone to copy their digital photos of "juniors" latest school concert and see how easy it is.

But this web-based email loop hole is a bit harder to police - technically. Which points out another major premise upon which we have to base so much of our network security - it's only partly (say 70%) about I.T. implemented safe guards. The rest comes down to common sense. You can't fight off the Indians outside the fort, if they are also running around inside the fort (thanks Gavin for that analogy). So this is where your best defense - or one of the best weapons in the arsenary is the job interview. If possible, or manageable, make some sort of common sense security screening part of the interview process. Of course this won't be easy or even possible if you're recruiting 1000 people a year but for small to medium sized companies, where security is an issue (all of them right?) don't underestimate the value of the job interview, for helping implement network security. Signing network acceptable use policies is common practice now and a great starting point - from that point on you have to opportunity to continually make network and information security am integral part of the company culture.

That's my rant over with - completely off the top of my head, and all because I read a line I liked in this article.

Lottery scams

I received another one of those lottery scam emails today - nothing new there, it's at least a weekly event for me and probably more like daily for anyone who is particularly active online.

Anyway, I read through it for a laugh - it made through the GMail spam filter, and got to wondering how anyone can actually make any money out of one of these scams.

Of course - the goal is broader than that - from obtaining funds from the victim in terms of money sent covering costs, to identity theft and in extreme cases even kidnapping.

Anyway, here's a nice link that explains things nicely.

SQL 2005 Database Snapshots

I read this article on TechRepublic about SQL 2005 snapshots this morning.

It's a pretty simple "how to" post showing how to create a snapshot of a database which is touted to be a great solution for reporting and even disaster recovery.

In my new role, I haven't even had a need to install SQL 2005 yet - so I reached for the DVD and thought I'd at least take the steps of creating a snapshot before commenting. But the process of running a few SQL commands to create a snapshot is not really the point here - the interesting part of this post (as is often the case) was in the comments. A couple of guys "go at it" - briefly - on the relative merits of snapshots in general. The main gist of it being - are they really worthwhile? Is a handy solution for a read-only, no locks database worth the hassle of creating a snapshot and maintaining a snapshot maintenance plan - which must be on the same machine and perhaps doesn't even solve anything with regards to lightening the load on that server. I don't purport to know the answer but frankly, in the small environments I'm used to working in, I don't think these snapshots will have a place. Too much planning, work and understanding for too little reward. I'm not the target market though, that's for sure! It will be interesting to watch this evolve though. Will it just disappear into obscurity like so many "major new features" or will it actually be the greatest thing since sliced bread? I expect the former but that's just me? I'd love to hear what real DBAs think of it - I'll have to go find one and ask him?

Another point on the Joel Test

Add two more to our score on the Joel Test - as of today, we are running automated builds - daily which can be run manually if need be, with one command.

This process, using NAnt, automates our VB6.0 builds would you believe - gets all the latest code, checks out binaries and project files for recompiling, moves them off to a deployment project and uses Wise Install Maker 8.1 to build a setup program. This program is deployed to our network and the testing guys and relevant developers are notified via email of it's success (or otherwise).

There is now so much more I want to automate, like release notes and changing statuses of tasks in our bugs/enhancement database, but one step at a time. I feel really confident that the decreased feedback cycle this will give us - from testing - will greatly improve the speed at which we close off outstanding issues - one of the major issues I've need to address since starting in this role.

Out of the Ashes...

Well the Ashes are over - a very satifying win for the Aussies after the disappointment of England 18 months ago. Time for a few posts here rather than all the focus on STUmpcam.

It's a great time to be working these past few weeks. I work on software for the building industry these days. The residential building industry pretty much shuts down over Christmas and the New Year giving me some very quiet time to focus on stuff that doesn't alway get the priority it should

We've brought on a new developer this past week who is working out very well it seems.

Also, automating the build process here is something that needs doing. This product is very mature - 10 years, has a well established market/customer base and yet still have heaps of potential for growth, both vertically and horizontally as well as geographically. There is plenty of legacy code and a few legacy attitudes but the good news is, every one is open to change and improvements. I've added a bit so far I feel, but in my attempts to add some agility, automating the build process is a "biggy"! We've certainly sped up iterations, tightened up testing etc but this build automation must be the next step.

I've made a good start...I've written down the tasks that must be automated, and even built the first couple. I have a few chinks to iron out, then a setup compilation to automate - my goal is to have the entire process, from getting the source code out of source safe, to having a CD ready for burning, happening automatically every night. There are those here that don't think it can be done, but I think that's more lack of exposure to this kind of thing talking, than anything else.

So let's just see. Then next think on my plate is to eliminate some strange errors the VB compiler (yep - it's VB6.0!!) is throwing back at me. Hmmm?