CrashTestChix

SANs or storage area networks, were a topic of discussion at this Lotusphere’s Gurupalooza.  See Paul Mooney’s post.

My comments included:

·         Educate yourself about SANs – you don’t have to be a hardware or a storage geek to learn the basics.  When you go into the next hardware meeting your eyes won’t glaze over when the SAN administrators start talking about controllers, and LUNs, etc., etc. 

·         Find out what Domino needs to run best on a SAN.  Here’s one IBM Technote 7002613.  The Storage Network Industry Association is a good source or contact your SAN vendor for advice.

·         Start keeping track of I/O statistics.  If you suspect that I/O is causing an issue with Dominoperformance begin recording statistics.  SAN architecture changes require planning, and can be expensive. Do your homework; have your statistics ready in order to justify your request.

You can run Domino on a SAN.  In our environment, we currently run everything, but the Notes data directory on our SAN.  This includes archive transaction logs.  So with careful planning and monitoring you can do this!

 

By Marie Scott and Thomas “Duffbert” Duff

In this installment, we’re going to delve a little deeper into Tivoli Directory Integrator by demonstrating how to update an external LDAP server with Domino Directory [Duffbert - Notes Address Book aka NAB or names.nsf using LDAP – for us developer types] data using a TDI LDAP connector.  This particular AssemblyLine will also stretch our TDI skills by require some JavaScript to parse the Domino data into the format needed by the external LDAP server. 

Before we begin this process, we need to have a Domino server that is running the LDAP server task.  We’re using an LDAP type connection for Domino for our demonstration.  We only need reader access to the Person documents in the Domino Directory because we are not updating fields in those documents.   Likewise, we are going to update records in the external LDAP directory, so we need the appropriate login credentials and update authority in the LDAP tree.  We are not deleting attributes, so we do not need delete authority in this example.

 In this particular AssemblyLine, our goal is to update some Domino-related attributes in our external LDAP server.  We’re including these values in our external LDAP entries for each person, so that Domino can be later configured to use the external LDAP as the source for HTTP, IMAP, and Sametime authentication. [Marie – Domino admins out there will note that Directory Assistance will be used on the Domino side for authentication…this is a handy trick!  Duffbert – yeah, yeah… get to the good stuff!] The attributes have already been added to the schema on the external LDAP server, as they did not previously exist.  What is important to note is that we need a unique key to match the records from Domino to LDAP.  In our example we use unid (which is an LDAP default identifier) and an employee id number.   The AssemblyLIne does not require two keys to link data attributes, but in this case we are using two, and as you’ll see the AssemblyLine will allow you to use multiple keys.

The attributes we’re going to work with are the following:

$dn

DominoUserAbbrev

DominoUserName

displayname

mailfile

mailserver

sametimeserver

employeeid

uid 

To get started we create a new TDI Configuration.  

Next we create a new AssemblyLine.

Now we’ll create a new Connector called DominoLDAP in “Interator” mode.

So now we have a Domino LDAP connector.  Next, we’ll create our connector to our external LDAP server.  This will work exactly the same as the one we just created, but we’ll call it EDIRLDAP and set it up as an “Add Only” Connector.

So how do we connect to our Domino server via the LDAP connector?  We connect using the LDAP url and port of our Domino LDAP server, with a userid and HTTP password that has access to read the Domino Directory. [Marie – we can also set up an SSL connection by selecting that option.]

We’re also limiting the LDAP search filter by using the objectclass=dominoperson.  This will give us only those attributes in the dominoperson schema.

We use the same method to connect to the external LDAP by connecting to the specific LDAP server and limiting the search base and search filter based on what we’re going to update in the LDAP schema.

Once we set up our login information, we’ll want to make sure we can actually “talk” to the servers via TDI.  To do this, we use the Establish Connection button (the little plug)

If all the information is correct in the previous step, we’ll see that a “Connection Established message.

Now, we can click the “Read the Next Entry” button (the little triangle) to cycle through the entries in the actual LDAP directory.  This will allow us to view real “live” data to confirm the formatting.

So to recap – we’ve created a new AssemblyLine, created two new connectors, and tested the connections.    What’s next?  Now we want to add the connectors to the appropriate places in our AssemblyLine. We can do this by dragging and dropping the “DominoLDAP” connector over to our AssemblyLine Feed indicator.  Add the External LDAP connector – as our AssemblyLine “flow” by the same method.

How do we pick fields we want to work with?  A couple of things to keep in mind – the Feed connector will have an INPUT tab and your Flow connector will have an OUTPUT tab.  These tabs are where we work with selecting our data fields also known as Work Entries:

Okay, these next steps are a little hairy so pay close attention.  On the FEED/INPUT Map – we have WORK Attributes.   These are the select group of data fields from our Domino Directory.  Some of these Work Attributes actually exist in the schema of the Domino Directory, and we can use them as is, so we can drag and drop them from the Schema View over to our Work Attribute list. 

Once we’ve selected a Work attribute, say for example “givenname”, if we know that we’re going to use that value as is, we can enable that in the Attribute Map settings (the Attribute Map is displayed when a Work Attribute is selected individually). So we’ve selected the Work Attribute by name in the Attribute Map as well as selected “Enabled” and type as “Simple”.

Now we do need to do some parsing, as the format from Domino does not match that of the LDAP results as we showed in the table above.  The method for making those changes involves pulling the data from the feed and making the change to the work items, and then parsing the data when it is output.  We’re going to use JavaScript to perform these operations.

Let’s start with one of the Work Attributes – mailfile.  Because the data in the mailfile field from the Domino Directory needs to be parsed, we use JavaScript to change how the data appears.  We do this in the Attribute Map Setting by selecting Advanced (JavaScript).

We also have some Work Attributes that don’t exist in the Domino Directory, but they will need to map to fields in our external LDAP directory.  So we click the Add New Attribute button.  In this example we are going to add a Work Attribute called “DominoUserName” that will use data from the Work Attribute called “$dn”, and we’re going to do some Advanced (JavaScript).

Once we have completed updating both the Work Attributes (Feed) and Connector Attributes (Flow), we should have the following fields with the appropriate coding:

$dn	Work Attribute	No advanced mapping;Enabled
DominoUserAbbrev	WorkAttribute	temp=conn.getString(“displayname”); ret.value=temp.toLowerCase();
DominoUserName	WorkAttribute	temp =conn.getString(“$dn).replace(“,”,”/”); ret.value=temp.toLowerCase();
givenname	WorkAttribute	No advanced mapping;Enabled
Mail	WorkAttribute	No advanced mapping;Enabled
Mailfile	WorkAttribute	ret.value=conn.getString(“mailfile”).replace(“\\”,”/”) + “.nsf”;
MailServer	WorkAttribute	ret.value=conn.getString(“mailserver”).replace(“,”,”/”);
Sametimeserver	WorkAttribute	ret.value=conn.getString(“sametimeserver”).replace(“,”,”/”);
ssn	WorkAttribute	No advanced mapping;Enabled
uid	WorkAttribute	No advanced mapping;Enabled
$dn	Connector Attribute	ret.value=”uid=” +work.getString(“uid”) + “,ou=people,org=domain”
DominoUserAbbrev	Connector Attribute	ret.value=work.getString(“DominoUserAbbrev”);
DominoUserName	Connector Attribute	ret.value=work.getString(“DominoUserName”);
givenname	Connector Attribute	No advanced mapping;Enabled
Mail	Connector Attribute	No advanced mapping;Enabled
Mailfile	Connector Attribute	ret.value=work.getString(“MailFile”);
MailServer	Connector Attribute	ret.value=work.getString(“MailServer”);
Sametimeserver	Connector Attribute	ret.value=work.getString(“sametimeserver”);
eduPersonID	Connector Attribute	No advanced mapping;Enabled
uid	Connector Attribute	No advanced mapping;Enabled

So how do we “join” the two separate sets of data?  We link them via our keys and the Link Criteria tab on the AssemblyLine Flow attribute.  As we said we’re going to make sure that our entries in the External LDAP server are updated only when the unid and $unid are the same AND when the employeeid is the same.  So we’ll link those attributes on the Link Criteria.

On the Flow Object – EDIRLDAP – go to the Link Criteria tab.  Click on the Add New Link Criteria icon (the little chain) and select “uid” as the connector attribute, “equals” as the operator, and “$uid” as the value.

uid is the value in the Domino Directory, and $uid is the value in the external LDAP Directory.

So we go ahead and create a similar link criteria for “employeeid” as the connector attribute, “equals” as the operator, and the attribute that contains the employeeid in the external LDAP directory.  [Marie: Attribute and value names don’t have to match when establishing them as link criteria.]

Now that we’ve set up linking, and customized our Work/Connector Attributes, our Work Entry view should look something like this:

Whew!  Now would be a perfect time to save the AssemblyLine configuration as we certainly wouldn’t want to have to rebuild all those connections.  And a word of caution before we proceed to the next step… As with any system, you want to make sure that you have a test environment to work with before you put this into the LIVE REAL WORLD!  TDI is very powerful, and could easily wipe data from the feed or the flow ends of the AssemblyLine.  So please don’t take our names in vain and say that we didn’t warn you!

So we’re ready to start our AssemblyLine and see how we’ve done.  We’re going to select Standard as our Run Mode and will click the start button to complete.

A tool that may come in handy when you’re working with LDAP entries on different types of servers is an LDAP browser, so you can review your data.  One we’ve used before is the Softerra LDAP Browser (they have a free version!).

Here’s one of our diagrams to display what we’ve done:

Using this example, you can now synchronize your Domino LDAP directories to all your other external LDAP directories without having to invest in an expensive tool to do so.  That should make you very popular with your boss, and may be a leverage point when you ask him for permission to go to Lotusphere!

If you having some difficulty justifying the upgrade to Domino 8.5, then do one thing.   Download the Domino Attachment Object Store estimator.  Run it, and then stand back.  You will be amazed at the numbers you will see. 

I'm currently running it against our archive server -- which occupies a 4 TB footprint.  The tool is still running after five days (this server has several thousand files), but the numbers I'm seeing are nothing but AWESOME!  For example a 12 GB mail database will be "smooshed" to 1 GB; another example - a 5 GB mail database to 624 Mb. 

You can certainly describe Domino 8.5 and DAOS as the incredible shrinking machine.  Your SAN/Storage folks will be happy, your backup/tape folks will be happy, and you'll be happy because you can take advantage of some of the other features like ID Vault, etc.  Be sure to check with your backup vendor to make sure they've got a mechanism for handling the NLO files (the objects that are removed during the DAOS process), and that the software supports ODS 51 (Domino 8.5).

So get going -- run the estimator, generate the numbers and hand them to your boss!

P.S. Wouldn't it be nice if DAOS would shrink calorie counts re: cookies, Peanut M&Ms, etc.? ;-)

I haven't posted a blog entry in some time.  As a university, we schedule many technology maintenance projects for the May through August time frame when fewer students and faculty are on campus. On my plate this summer has been the deployment of Google Apps for Education to our incoming freshmen class, the continued roll-out of Notes 8.5 to our faculty and staff, and the upgrade of several servers to Domino 8.5. 

The Google Apps for Education deployment has been an interesting experience needless to say.  Google recommends a six week time period from start to finish.  We were able to deploy two weeks early.  Thanks go to some very able programming staff here who were able to integrate the Google API and Postini directory process with our current LDAP account create process.  We continued to maintain student entries within the Domino Directory so that faculty/staff will be able to email students using Notes.

A important reminder for those who might be reading this - Google Apps for Education - is free to universities.  FREE.  And students, for the most part, LOVE Google.  Or at least Google is that system with which they are most familiar (that is my theory regarding their apparent affection for Google).  We have implemented single sign-on with the SAML API that works with our Central Authentication System or CAS-based system that we use for our portal and other web systems.  It does have a draw back.  If you use SAML, SAML does not provide password authentication to IMAP or POP.  So users must use a separate non-synchronized password for IMAP or POP access.  Google Apps for Premier customers also have access to Postini spam/antivirus reports for analyzing inbound traffic, etc.  Education customers do not receive access to that feature set.  Management of the Google account process is through APIs or the Postini directory synchronization product.  We used Postini to get a large group of users imported, but are considering moving to the Google APIs for more granular control, as we are seeing many false positives with error reports in Postini.  We have also had some issues with creating portlets that would work with our current portal (Oracle) and our future portal (Liferay) as there are limitations with the implementation of 2-legged OAuth vs. 3-legged OAuth.  When Google Support was contacted to discuss this, we received a rather ambiguous response in terms of when the technical issues would be resolved. Of course this is type of response is not unlike other software vendors.

When Google moved from being a beta to non-beta product, we did not receive notification, nor did we receive a system-wide alert about the label architecture changes that took place globally (despite having set up notification options in our Google domain).  With global web changes taking place on 10,000 web accounts, it was a bit disconcerting not to receive some warning.

On the Notes/Domino side of the house, our Notes 8.5 migration continues to roll forward with the primary issue being upgrading workstations that do not have more than 512 Mb of memory.  We have seen overall that the Notes 8.5 standard client requires 1 Gb or more on Windows XP - hands down.  From a user perspective, the users have required minimal training and continue to comment positively on features that they find useful.

I am preparing to upgrade our archive server to Domino 8.5 from Domino 7.0.3 over the next few weeks.  I'm really looking forward to implementing DAOS on this server as it is currently a disk and backup resource hog.  The disk footprint alone is 4 TB.  I have not had an opportunity to run the DAOS estimator, but I'm sure I'll see many GBs of disk savings, and will be sure to post our results.  This server contains data going back to 1991 for some faculty! 

I hope others are enjoying some lazier days this summer! Have fun! :-)

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.

I read Stephan Wissel's post yesterday and am so thankful I did!  I've been trying for years to describe the self containment of Domino as an application development platform to co-workers and managers.  I need to look no further - Stephan's diagrams were right on!  Bravo!  I then wondered - what if you could take those same concepts a few several steps further and extrapolate exactly how much time or manhours are required to implement the non-Domino solution versus the Domino solution?  Wouldn't that provide a black and white comparison that could be used as a knife edge marketing tool?  Have we been missing this all along?  What about a competition say between a set of Sharepoint developers or standard web developers and a set of Domino developers to create the same web application....how many servers, how many man hours?  Is there be a set of measures that could be used to nail this once and for all?  Perhaps this would banish the concept that Domino is NOT only an email server? Maybe someone should give Denis Leary a call to act as the spokesperson! ;-)

One of tools that I consider a genuine "Swiss Army Knife" when it comes to connecting disparate data sources and directories is Tivoli Directory Integrator.  Here are a few links to point you in the right direction if you are interested in delving deeper into learning more about TDI.

One of the first places to visit is the IBM Tivoli Directory Integrator Users Group.  This users group includes sources for TDI training, glossary of TDI terms and concepts, Javascript tutorials, tips and hints, as well as step by step examples.

Integrating Lotus Notes/Domino with Tivoli Directory Integrator, authored in 2008 by Eddie Hartman, a member of the TDI Development Team.  This wiki includes a sample CVS file to use to step through the exercises outlined in the wiki.  The wiki also contains chapters on using TDI with Domino databases – other than the Domino Directory, and documentation regarding the different types of Lotus Notes/Domino connectors that ship with the Tivoli Directory Integrator.

And here's a recent posting on developerWorks about using TDI with Lotus Connections.