point-n-click

Immediate Call Forwarding: Dial *21* plus the 10-digit number to which your calls should be forwarded and #. Press Send. Busy Call Forwarding: Dial *67* plus the 10-digit number to which your calls should be forwarded and #. Press Send. Call Forwarding No Reply : Dial *61* plus the 10-digit number to which your calls should be forwarded and #. Press Send. Call Forwarding Not Reachable : Dial *62* plus the 10-digit number to which your calls should be forwarded and #. Press Send. unlike this http://www.wireless.att.com/learn/basics/choosing-features-services/call-forwarding.jsp reference sheet, the above are direct ways of manipulating the call forwarding features that many of us enjoy (without knowing).

Just over another hurdle in the SharePoint steeplechase. This one involves the glorious PeopleEditor control and how to make sure the user has some client-side feedback before they post their selection. Through the nest of blogs and comments about the general ASP.NET versus the universe of SharePoint problem, the best solution seems to revolve around hacking the client side javascript and doing the most manual processes imaginable to get consistent validation. Precisely, I mean that within the PeopleEditor should support simple validation out of the gate, but the AllowEmpty property doesn't work (see Karine Bosch’s comments from this blog link ). Then you end up going through the following failure steps before the aforementioned hack emerges as the winner: AllowEmpty property of PeopleEditor (Karine Bosch’s link ) #FAIL ValidatorEnabled property of PeopleEditor (Karine Bosch’s link ) #FAIL Adding the ASP.NET RequiredFieldValidator element within the ASP form (shereen's bl...

It seems like there are hundreds or thousands of people out there that have come across this little SharePoint sendemail bug. Beware this error message is a red herring! My suspicion is that through a series of unfortunate events around the sequencing / pipelining of workflow activities, the sendmail activity gets terminated prior to having a chance to become a fully dehydrated object. Postulations aside, here is the fix I used: Observation 1 from 12's hive logs (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS): w3wp.exe (..) 0x.. Windows SharePoint Services, General, 8kh7, High, Cannot complete this action. Please try again. Observation 2 from Workflow History: Error, System Account, The e-mail message cannot be sent. Make sure the outgoing e-mail settings for the server are configured correctly. So I fixed my <sendmailobject>_MethodInvoking by binding the sendmail activity's email fields (to:, cc:, body:, etc) to class variables and then ass...

MOSS removes the association between workflow tasks, history items and the workflow 60 days after the workflow has been completed through the workflow cleanup timer job for performance reasons. Consider this next suggestion a workaround for that bad design; most companies that develop custom workflows will want that history around for some time. Several alternatives are available, albeit brute-force methods, but the one I elected to go with is to place the following bit of configuration in the workflow.xml prior to associating a workflow. workflow.xml <Elements> <Workflow> .. <MetaData> <AutoCleanupDays>9999</AutoCleanupDays> </MetaData> .. See Brian Farnhill for more documention on this issue.