CrashTestChix

Yesterday's Techrepublic Webcast regarding Hamilton Beach moving to Google, and Ed Brill's subsequent post generated some lively discussion on Planet Lotus, Twitter, and in my office.  I had lots to think about during the drive home last night!

As I sat sipping my early morning coffee today, I wondered if  IT organizations had the same amount of money available to them today as they did in 1999 when preparing for Y2K - all other factors remaining the same - would Google Apps be as attractive as an enterprise solution? I'm not so sure.  Many of the organizations that are moving to cloud computing are using cost savings as their primary reason for moving to cloud based collaboration systems.  So given economics as a constraint, many organizations are willing to sacrifice customer service, technical support, upgrade support, product stability because the cloud option is "cheaper."  Or are they using that only as an excuse?  

Haven't we all read about IT organizations that have implemented systems (any) only to turn around and literally rip them out a few years later because they were poorly implemented or poorly managed?  Isn't it a management strategy to frequently blame it on the old system and prosthetize that the new system will most certainly be better?

And collaboration systems are unique in that they REQUIRE colllaboration. Collaboration between IT staffs, collaboration between user groups and technical groups, and collaboration between management and technical staff.  So that everyone is on board with a common set of goals and objectives for the system.  Otherwise, it is collaboration failure.

So while Google Apps may be the cost/effort saver du jour, if the collaboration infrastructure is not fostered, if users are not trained and offered solutions for accessing tools from remote locations, and nuturing of the client base does not take place, then we may read in a few years about Google being replaced by some other product at organizations like Hamilton Beach.  Maybe back to Lotus Notes/Domino!  ;-)

Take a few minutes to watch the online demo of the new computational search engine developed by the folks at Mathematica and Stephen Wolfram.  The search engine is scheduled to go online tonight at 7 PM CST.  The search site is different in that it will provide answers to factual questions.

A friend shared this with me this morning...it applies to so many things in our world today, including Lotus Notes/Domino!

http://www.youtube.com/watch?v=rOtEQB-9tvk&feature=related

I'm preparing to deploy the re-signed Java Applets and two sets of iNotes/DWA hotfix sets across more than 50 servers this weekend.  And I'm reminded of an entry I wrote in March about "The List."  This refers to the actual list of items I take with me to Lotusphere each year to discuss with the development teams. My staff tease and joke about "The List."  "Is this one of those items on The List?"-- as they know I take this very seriously.  And each year I usually walk away with some sense of satisfaction knowing that I had some "face time" with those that may be able to resolve a particular issue. 

So....this leads up to the first item that will be on The List for Lotusphere 2010.  That is the packaging of iNotes/DWA hotfixes and any type of Java applet fixes.  Currently this type of hotfix is a manual copy and paste fix across all platforms.  There is no executable provided by Lotus Support to replace the files as is the case with other types of hotfixes or incremental upgrades.  This is a serious service issue.  On a unix platform, each file must be copied with the correct ownership and file properties.  No matter what size Domino domain you are managing, this is a time waster.  Could I write an executable to do this for me? Sure.  But considering that file names and file locations might change each time, this might equally be as time consuming to manage. 

Lotus Support, please consider developing a packaging mechanism for these in the future.  See you in the Developers' Lab next year!

I was preparing for our maintenance cycle this weekend and the installation of the Java signed applets, and noticed the following outage listed for this weekend on Fix Central:

Be sure to go ahead and download your Java Signed Applets now from Fix Central or from the IBM FTP Site included in the technote 4022981.

If you're a Domino Administrator, and you've had to troubleshoot a Notes database with a corrupt Access Control List (ACL), you know what  is a nightmarish experience this can be!  Especially if you don't have a replica or backup copy of the database (all the more reason to make sure you do!).  The first step to take is to run a fixup (or fixup -J if you're running in a transaction logged environment).  If the fixup process cannot repair the corruption, you may be able to fix the database with a tool like Ytria's ScanEZ (I have done this by editing the ACL with their tool, but this does not always guarantee success).  However,  IBM Support recently published a technote 1195064 which includes some suggestions for resolving ACL corruption.  File this away in your "toolbox." Here's hoping you never have to use it!  :-)

Ok admit it administrators.  You have created custom views in the Domino Directory.  I've done it myself.  I have several that I use on a daily basis.  For example, a view of users sorted by certifier or one that lists users by group membership.  Some of these views may be "public" in that they were designed to streamline some directory data for your users. But I suspect that many of them were designed primarily for administrative purposes only. 

So think about that.  Do you really need those specialized views to be available to your users?  And what about the default Server config views, do you really want all your users to have access to that information?  No.  Do you want pesky developers second guessing why you have restricted their access to server agents?  No!  So do yourself a favor, HIDE THE VIEWS.  You have the ability to hide them based on reader roles that are already in the default ACL of the Domino Directory or you can add specific ones.  You can also take advantage of design properties that hide views from either the view menu, folders pane, or from web access.

For those Custom views you've created for your own administrative needs,  I'd recommend restricting access based on a reader list. You may want to add a special administrator's role or group to your Domino Directory that you can use for this purpose.  To accomplish this:

1. In Domino Designer
2. Open the view, and select View Properties
3. Click the Security Tab
4. Deselect "All Readers and above."
5. Cick each user, group, server or access role you want to include. A check mark will appear next to the name or group.
6. Save the view or folder.

You can also use this method for hiding Server configuration views, so be sure to include the LocalDomainServers and LocalDomainAdmins group in those included as readers.  Do this in your test environment first to make sure that you are not restricting access to a view that has been customized for a particular third party application or user.

Another method for restricting view access is to omit the view from either the view menu, folder pan, or from web clients.

1. In the View Properties box - deselect "Show in View" menu on the options tab.  (this only applies to Notes users).
2. To hide the view from the Views - Go to View selection option, give the view a name and enclose it in parentheses.
3. To hide the view from web clients, click the view name in the Design toolbox righ pane, and choose Design - Design Properties. Select "Hide design element from Web clients." Give the view a name and enclose it in parentheses.  This will prevent the view from being available from the Go to View selection in the client as well.

I also would recommend keeping a separate database as your "warehouse" for your Domino Directory customized views.  If you only use them occasionally, why keep them in the Domino Directory all the time?  Create a separate database to store the view design elements and drop them in the Domino Directory only when you need to use them.  Thus saving some cpu, updall and full text indexing overhead on your server. 

And once again - test, test, test and test again before implementing in your production environment!

The certificate for some Domino java applets will expire on May 18, 2009.  See technote 1381298  This affects versions 6.5.x through 8.5.x. 

The technote includes FAQs and download instructions.  See also the reference to Sametime Applet certificates expiring on May 18, 2009.

Check out Technote 1380778 regarding Sametime applet certificates in the meeting center expiring on May 18, 2009.  See the technote for downloads.  Users will be prompted regarding the expiration of the digital certificate. 

You may be thinking...hmmm..hide a user. Domino administrators at one time or another have wanted to make a few users "disappear into thin air" or at a minimum have wanted to ship them to another planet. But (unfortunately) this is not an article about the intergalactic kidnapping of end users.

I was recently asked to prevent the display of a user's name in the Domino Directory. I thought about this for a bit, and despite the obvious question of "why?" I thought that perhaps with the Security Tab on the Document properties I might be able to pull this off.  But first, I needed to investigate the request further.

1. Should the user's name display in the Notes client type ahead feature?  <No>
2. Should the user's name display in any pull-down listing for the Domino Directory?  <No>
3. Will the user send and receive mail?  <Yes>
4. Will specific staff have access to either (1) the Notes native name or (2) the internet address of the user? <Yes>
5. Will calendaring and scheduling be utilized and if so, how? <The user's administrative assistant will schedule appointments, but busy time will not be available for viewing.>
6. Will the user access mail/calendar via Blackberry/PDA?  <Yes>

So my next step was to create a test account upon which to perform the "scientific" experients of "invisibility."

After creating the test account, I performed the following steps.

1. In the People View in the Domino Director, highlighted the Person Document.
2. Right clicked on the document, and selected Document Properties.
3. On the Security tab, unchecked "All readers and above", and placed a checkmark next to LocalDomainAdmins, LocalDomainServers and our generic admin group account.

I switched to the Notes.id of the test account, and ran through my checklist of user functions.  Created mail, sent mail, created calendar events, did address book lookups, etc.  I then switched to a Notes.id that did not have access to any of the groups included in the Reader List of the "hidden" user's Person document to determine if the user was indeed "invisible."  Again, I ran through my checklist.  I searched for the hidden user using a type ahead -- not found, pull down list - not found, did a search from the search view - not found.  I explicitly typed the internet address in the To: field and was able to send mail; but this was acceptable as certain individuals were to be given the internet address for mail routing. 

What was next?  To actually "hide" the user in question.  If you do need to use this method, be sure that you are included in a group that is listed in the Readers field.  And try this method in test - several times until you feel comfortable with it, before putting it into production.  Because you certainly wouldn't want to hide your manager, or your CEO unless you meant to!