Monthly Archives: July 2010

Google announces User Policy Management for Google Apps

Google has been released a number of new features for Google Apps domain administrators including yesterday’s announcement regarding user policy management.

While these features are all stepping the Google cloud in the right direction in terms of user management, what is perplexing to me as a Google administrator, is you’re never notified when those changes are going to occur in your domain.  The cpanel interface in the domains that I manage looks nothing like what Google portrays in their “future” screen prints.   So maybe I’ll login one day and poof our domain will have been “upgraded.” 

So just a word — Google, Microsoft, and IBM please take note – cloud administrators like to be notified in advance when changes are to occur!

Are you ready for IamLUG?

There’s still time to sign up to present (a few slots are left) or to attend!  Don’t miss out on this unique opportunity!

Be sure to check out the recent announcement about 50% off Lotus Certification.  And the TackItOn is a great opportunity if you want to turbo start your skills in Domino Optimization, iPhone development or xPages.

See you there!

A Follow-up: iNotes Failover

I suggested a method for using the iNotes redirect database as a means for providing iNotes failover in the event of a disaster or during maintenance periods.  I want to follow up on the post due to some comments I’ve received.

As with any other Domino process, there are possibly many ways to provide failover.  This is certainly only one means of doing so.  And I’m certainly in no way suggesting this is the ONLY way or the BEST way.  In our environment we also provide load balancing and failover using the Websphere Edge Server, which I have also blogged about previously.

We have multiple copies of the Autologin form based on the type of failover we want to do, and we simply rename the form.  So we are not recoding the $$HTMLHead field change each time we want this failover to occur.  And, because we are using the redirect database to redirect at the domain level rather than the server level, creating separate redirect profiles has not been the most effective means of providing the same level of failover.

I hope that what you have walked away with is the realization that you can customize the redirect database to suit your needs, and as with any other Domino process, you can in your test environment, experiment to see what works best for you!  Good luck!

Need a solution for iNotes failover? It’s as simple as a few lines of code!

Have you ever had a set of cluster servers fail – perhaps due to a hardware outage?  And iNotes users on those servers are no longer able to connect to their primary server or automatically failover to their cluster mate. 

Or if you’re doing maintenance on one set of cluster servers, and want to have your iNotes users connect to their cluster mate during the maintenance period, you can do that.  Here’s how. 

If you are using the iNotes Redirect database based on the iwaredir.ntf template, you can make the following modifications to the database which will replace the server name in the URL string with the corresponding cluster server name. 

In the database, find the AutoLogin Form.  It contains a field called $$HTMLHEAD.  The $$HTMLHEAD field builds the URL string to direct Domino to the server and database name of the user. 

In the formula language of this field, look for the following lines of code: 

ServerNameChange=”2″;@If(RevProxyServerName=””;wmrhttps+”://”+wmrHTTPHostName+wmrFinalPort;RevProxyServerName+”/”+wmrFQDNHost); 

Replace the code with the following: 

ServerNameChange=”2″;@If(RevProxyServerName=””;wmrhttps+://”+@ReplaceSubstring(wmrHTTPHostName;”ClusterServer101″:”ClusterServer102″:”ClusterServer103″;”ClusterServer201″:

“ClusterServer202″:”ClusterServer203″)+wmrFinalPort;RevProxyServerName+”/” +wmrFQDNHost);

What this will do is replace the following in your URL string: 

ClusterServer101 is replaced by ClusterServer201 

ClusterServer102 is replaced by ClusterServer202 

ClusterServer103 is replaced by ClusterServer 203 

Thus the user will be redirected to their mail file on the cluster mate without having to take any action or even realize that they have been “redirected” to their cluster server. 

We have used this method for 5 years in a very large cluster environment.  Our code is a little simpler as we have distinct names for the Servers between clusters, so we only have to use the following code: 

ServerNameChange=”2″;@If(RevProxyServerName=””;wmrhttps+://”+@ReplaceSubstring(wmrHTTPHostName;”Alpha”:”Beta”)+wmrFinalPort;RevProxyServerName+”/” +wmrFQDNHost); 

This recently was put to the test when a colleague of mine was able to use the same code during a disaster situation when approximately 3000 iNotes users were unable to access their mail.  Once he implemented this code, they were seamlessly redirected to the cluster set that was available and continue with their work!  And when he shared the code with IBM Support…their response was “brilliant!”