BLODEX

Category Lotus Notes and Domino 8 Lotus Notes and Domino Issues
Bookmark :              

I've discovered another bug in the Notes 8 standard client. The QueryDragDrop and PostDragDrop events in the Database Script object (Domino Designer > Other > Database Resources) does not seem to be working the same way as it used to in Notes 7 and still does in Notes 8 basic. This means than some of the IBM's original code in the mail 8 template that developers placed in the PostDragDrop in particular is not working as intended. For example, this piece:



... which is there to prevent people from drag & drop operations on Group Calendar documents, works correctly in Notes 8 basic, but does nothing in Notes 8 standard. This means people are able to drag Group Calendar documents to any folder. Similar code has been deployed in there by IBM to prevent people from dragging & dropping other elements, such as Mail Rules. the fact that this no longer works is a serious problem because by dragging/dropiing people can now remove rules from the Rules folder (yes, it is a folder) and put them into some other folder. Unfortunately, they cannot drag them back into the Rules folder. I believe I reported this to IBM months ago while Notes was still in 8.0 but it does not seem like this got too much attention. Their answer at the time was: use workaround that is use a basic client... How disappointing.

The underlaying reason is the fact that the sequence of execution in the source code seems to be different between basic and standard. While in Notes 7 and Notes 8 basic the "source.Documents" in this context returns a handle to the document collection representing documents that the user selected before drag & drop operation, in Notes 8 standard this is not the case. Instead this ends up being a handle to a single document that Notes shifts focus on after drag/drop operation has been executed prematurely.

To illustrate this, I put some debug code in the QueryDragDrop and PostDragDrop events in the Database Script object:





When you drag and drop documents between folders in this test database based on the Mail 8 template, you will get different results depending if you use Notes 8 basic on standard:


NOTES 8 BASIC (same as in Notes 7)



Note that when the dialogue box comes up, at this point selected document are still where they are. They were not yet moved to a target folder. This box shows document count for the Document Collection representing selected documents.

Also note that QueryDragDrop has already been executed correctly hence you see the message in the status bar from the "Print" statement I added there.



NOTES 8 STANDARD



The first capture was taken before I released the mouse button during the drag/drop operation (only drag, not drop yet). Note that QueryDragDrop has NOT been executed at all hence you see no message in the status bar from the "Print" statement I added there.




This second capture was taken after I released the mouse button during the drag/drop operation.

Note that when the dialogue box comes up, at this point selected document are no longer in their original location. They were not yet moved to a target folder (I know that from a separate test) but they were already removed form the source folder. In addition the handle to the Document Collection representing selected documents was already lost. Hence, the document count is zero. If there were other documents in the source folder, Notes would have shifted it focus to the first one and the resulting source.Documents would have been 1.

I'm not sure if someone already reported this to IBM. I intend to open a PMR for this as soon as I finish documenting it here. I will be posting the updates based on their response.

Sample database with a debug code can be found in the downloads section of my blog.

Posted by Bodek Frak At 01:04:24 PM Location Windsor - U of W | Permalink | Comments (2) | TrackBacks (0)

Category Domino Development Domino Administration Lotus Notes and Domino Issues
Bookmark :              

I have just discovered an issue that I would like to share with other Domino developers and administrators.



The ACL of each database has a setting on the Advanced tab that specifies an action that should be performed by the server listed as the Administration Server on the ACL (the one with the gold key icon next to it) in the event of the user name change. I discovered that a default value for this setting is "Do not modify Names fields". This can create lots of problems if you use Readers or Authors (aka Names) fields in your design to restrict users' access to individual documents inside your application. When a user gets his/her name changed (marriage, divorce, etc.), the Administration Process task running on the designated Administration Server for your database updates his/her old name to the new name on anything that it can find, including the Names fields. However, with this setting configured to "Do not modify Names fields", the update will never happen and the user will be locked out of the documents he/she previously had access to. This is bad. Nobody wants that, I'm sure...

Another issue can arise if you do not have any server on the ACL designated as Administration Server, or if you designated a server that does not host a replica of your database. Your Names fields will not be updated even if the above setting was set correctly.

I would like to urge you to go through all the applications that you developed where you made use of the Names fields, or even restricted the access to views using view properly settings (security tab) and ensure that the ACL of those databases is configured correctly:

• always list one of the servers as the Administration Server
• make sure your database has a replica on that server
• make sure Administration Process is in fact running on that server (check with your admin)
• always set "Action" to "Modify all Names fields" to allow user names in Readers/Authors (and other) fields to be updated by the admin server when any user gets renamed.
  
  I will also suggest to IBM that they change the default value for this setting to make things easier for us.
  
  

Posted by Bodek Frak At 12:14:55 PM Location Windsor - U of W | Permalink | Comments (3) | TrackBacks (0)

Category Lotus Notes and Domino Issues
Bookmark :              

This is a follow-up to my blog entry from Nov 7, 2008:
QueryDragDrop and PostDragDrop bug in Notes 8 Standard

Recently, I opened a new PMR to find out if this issue has been resolved by IBM-Lotus developers, and this is what I got in response:

"SPR CJON7L73CK (NotesUIDatabase.Documents method returns incorrect information.) has been closed. Apparently there are no plans to fix this issue."

This does not seem to be the case, however. I did the same test in Lotus Notes 8.5 today that I did back in Nov 08 with Notes 8.0.1 when I blogged about this issue. I used the same "PostDragDrop Bug Sample Mailfile" that is available on my blog in downloads section. I discovered that the issue has been resolved and the number of documents reported by NotesUIDatabase.Documents is now correct. Perhaps IBM developers have no plans to address this in the 8.0.x code stream..., but in 8.5 it is working as it should.

Posted by Bodek Frak At 10:16:30 AM Location Windsor - U of W | Permalink | Comments (0) | TrackBacks (0)

Category Lotus Notes and Domino Issues
Bookmark :              

A very strange thing happened after we upgraded our call tracking software HEAT (FrontRange Solutions) to the more recent version 9. Anyone who had Lotus Notes installed prior to the HEAT upgrade, have noticed that their Notes password prompt got replaced with a box that looks just like text input box that LotusScript code can produce. So we went form this:



...and this:



... to this:



I don't think there was any doubt in anyone's mind what the culprit was, but since HEAT is someone's pet project here, this issue was being down played and was labelled as "limited scope". Our HEAT admin sure took his time in trying to pursue the vendor for a solution to this problem (of course downgraidng HEAT was out of the question), and after weeks of not much happening we got the word that there is no solution but we have workaouround: un-istall Lotus Notes, and re-install Lotus Notes. Apparently vendor of HEAT was not very co-operating in trying to get to the bottom of this. At one point (as we were told) they even said that it's not their problem and that we should contact the IBM... Shortly after, my colleague discovered this strange file that appeared in ../lotus/notes folder around the time HEAT was upgraded:



When he renamed it and moved it to a different folder, his Notes password prompt came back from the dead. Unfortunately, this did not work for me or our HEAT admin. So few more weeks went by, it looked more and more like the only hope we have is that wonderful workround suggested by FrontRange tech support. It was yesterday, that I took some time to search the Web for the HeatSetLotusPassword string. Did not find much there, Google returned only two hits - two posts on the HEAT related forums that included more questions than answers. Searching though my Windows registry also did not yield any results. There was only one more place to check: notes.ini. As I was making my way up starting from the last line, I then came across this:

EXTMGR_ADDINS=HeatSetLotusPassword,extpwd





How did we not see this coming? Needless to say, removing this line (or commenting it out), took care of the problem and after restarting Lotus Notes, my password prompt was back.

Posted by Bodek Frak At 08:10:13 AM Location Windsor - U of W | Permalink | Comments (1) | TrackBacks (0)

Category Lotus Notes and Domino Issues
Bookmark :              

Starting with Domino 8.5.1, LOG_SESSIONS parameter in notes.ini can be set to "2" to include additional information (text in bold) about Lotus Notes sessions with Domino server.

01/12/2010 09:35:45 AM Opened session for 'John Smith/University of Windsor' (Release 8.0.2) SessId 06BE22DB Ip '177.52.15.83' 'Auth' 'C'


Before 8.5.1, setting it to "2" did the same thing as setting it to "1", that is displayed the session info on the server console, AND logged this same information to log.nsf.

01/12/2009 09:35:45 AM Opened session for 'John Smith/University of Windsor' (Release 8.0.2)


It appears that with Domino 8.5.1 and  LOG_SESSIONS=2 in notes.ini, this information no longer gets logged into log.nsf although you can still see it on the server console. Setting  LOG_SESSIONS=1 still works properly, ie. the info shows up on the server console and inside the log.nsf.

IBM Technical Support confirmed that they are aware of this issue:

Lotus Notes SPR # DSAN7XH3LD                                            
Session information not written to Misc. Events in log.nsf after upgrade to 8.5.1 using Log_Sessions=2

Posted by Bodek Frak At 09:49:01 AM Location Windsor - U of W | Permalink | Comments (0) | TrackBacks (0)

Category Lotus Notes and Domino Issues
Bookmark :              

In previous releases, LOG_SESSIONS=1 would produce session info output for all IMAP client connections to the server on the server console and log it in log.nsf:

example:
"12/22/2000 09:26:01 AM  IMAP Server: Jane Doe/University of Windsor logged in from 117.27.50.17"

I was just made aware that this is no longer happening in Domino 8.5.1. This may be related to SPR # DSAN7XH3LD (which my previous blog post is about) or not,  since this relates to IMAP while the SPR deals with Notes client connections.

Posted by Bodek Frak At 11:53:53 AM Location Windsor - U of W | Permalink | Comments (0) | TrackBacks (0)

Category Lotus Notes Tips Lotus Notes and Domino Issues
Bookmark :              

One of the new features in Lotus Notes 8 is a preference setting in your calendar that would allow Notes to process meeting cancellations automatically for you, and allow you to specify if you want the cancelled meetings "removed from calendar", or "shown as cancelled in calendar" after Notes automatically processes them:



The question that is being asked frequently is "Why do cancelled meetings not show in my calendar even though I enabled this option in my preferences?"

Some users assume that with this setting on and configured to "show as cancelled in calendar", they get to see cancelled meetings in their calendar indefinitely, or until they decide to remove them. This assumption, however, is incorrect because, this is not how this new feature was designed to work.

Help file is very unhelpful in this case, as it does not really explain anything, and it just restates the obvious:



The article "Keep your Inbox cleaner - set preferences for meeting invitations (Lotus Notes 8.x Tips)" by Julia Brown on IBM's developerWorks made me realise what this feature is all about.

First, you have to decide if you want Notes to automatically process meeting cancellation notices for you (new in Notes 8), or if you want to continue with the pre-8 functionality, that is manually process each cancellation by opening cancellation notice delivered to your Inbox. By default, automatic processing is turned off. After enabling autoprocessing of meeting cancellation notices, you get two choices that are otherwise grayed out:

Remove from Calendar - When you pick this option, the cancellation notice will not appear in your Inbox folder at all because as soon as router delivers it to your mailbox, it will be processed and the meeting document will be removed from your calendar. You will only be able to see the cancellation notice in All Documents view in your mailbox. The potential problem with this option is that you will not get a chance to acknowledge the cancellation unless you frequently check All Documents view in your mailbox. You may not even realize that the meeting entry has disappeared from your calendar, and you may still attend the meeting. If you notice that the calendar entry is gone, you may suspect that Notes is malfunctioning and is erroneously deleting your calendar entries. We do not recommend to use this option unless you are fully aware of its limitations and are willing to take a risk.

Show as cancelled in calendar -  When you pick this option, the cancellation notice will appear in your Inbox folder until you delete it or remove it, although the router still processes the cancellation notice as soon as it is delivered to your mailbox. After the cancellation notice is processed by the router, the cancelled meeting will continue to show in your calendar, although in a different colour (red/maroon) and with a different icon:



...but ONLY until you either open the cancellation notice in your Inbox (including displaying it in preview pane), or open the cancelled meeting document in your calendar. As soon as you do that, Notes displays an "Update" message and removes the cancelled meeting from your calendar (but the cancellation notice stays in your Inbox). Perhaps what this message should say instead is "The calendar entry will be removed to reflect this change", instead of "will be updated".



Notes removes your calendar entry to keep your calendar "less cluttered" (as intended by the IBM developers).  

How is the second option different from not having autoprocessing of meeting cancellation notices turned on at all? It's important to keep in mind that the main goal of autoprocessing of meeting cancellation notices is to free up the time slot in the "free time lookup" database originally occupied by the cancelled meeting. Even if you did not get a chance to acknowledge the cancellation notice yet (perhaps you are away for a few days), people trying to invite you to a different meeting scheduled on the same date and at the same time as the cancelled meeting, will now see you as available.

Some Notes users here suggested that this functionality be modified in the next release to provide the option for cancelled meetings to remain in your calendar until you decide to remove them.  It looks like some people outside our organization feel the same way (see "Cancelled Meeting does not Show up in Calendar - IBM's Answer" post on Notes 8 forum by Shawn J Kiser.) Here's IBM's position on this:

"The associated SPR (KWSR7LZQ2G) has been closed as "No Plans to fix in this release". Another SPR (MSTR7LDLCW) describes the same symptoms, against v8.5. The status of SPR (MSTR7LDLCW) is currently "Closed/enhancement request". Thusly, feature development is treating this issue as an enhancement request: We are adding further customer reports of this issue to SPR (MSTR7LDLCW) -- so the customer impact is reflected in the weighting. If weight increases sufficiently, as a result of any additional customer reports, the issue may be reconsidered for an upcoming maintenance or feature release"

I suppose all this makes sense if you keep in mind that the main objective of this feature was to free up your time in the "free time lookup" database so that people can see you as available even if you did not get a chance to process the cancellation notice yet.

Posted by Bodek Frak At 01:52:12 PM Location Windsor - U of W | Permalink | Comments (1) | TrackBacks (0)

Category Lotus Notes and Domino Issues
Bookmark :              

It's common sense that tor the survey to be truly anonymous, the name of the person taking it cannot be stored anywhere inside the document after it was saved/submitted by the user. This applies to both visible and hidden fields. The same is true for an on-line voting application, and other similar applications that are advertised as "anonymous".

Things are easy for the developer when the user who submits the on-line form on the Web was not required to authenticate ("Anonymous user") in order to participate. But what about the situations where authentication is a must in order to establish person's identity to see if this person is eligible to participate? And what about Lotus Notes users where there is no such thing as "Anonymous user", since every Notes user is authenticated from the moment Notes is launched?

Even if the developer will not add any fields to the form that are designed to capture user's name, for the survey to be truly anonymous steps must be taken by the developer to address the $UpdatedBy field. This is a special hidden item (ie. field) that Domino/Notes adds to every document automatically. It is a multi-value item designed to store a list of people who have updated a design note (eg. document), with its first value being always set to the original creator (aka author) of the document. The item returns Anonymous as the user only if:

• • A document is created by a Web user with Anonymous access to the database (as per ACL) in which the user is creating the document, (assuming no prior authentication took place in the same session).
  • A form is set to “Anonymous Form” by the developer in the Form properties box, which tells Lotus Notes and Domino not to record names of people who create or edit documents.
  
  
  
  
  
  The example below, shows document properties for two documents created with the same form in Lotus Notes 8.5 client. The first one (first row in the screen capture) was created when "Anonymous Form" property was turned off (ie. box not checked). The second row shows a document created with  "Anonymous Form" turned on (ie. box checked). As you can see, when Anonymous Form is enabled, Lotus Notes no longer adds $UpdatedBy item to the document, and instead it adds a different item called $Anonymous with a value of "1" (data type text string).
  
  
  
  
  Strangely, when you enable this option on the form, it will do what it is designed to do if you create a new document with this form in Lotus Notes, but when you use a Web browser to create and submit your document with Anonymous Form property enabled, Domino just ignores this setting. User name will be captured and stored in $UpdatedBy just as if "Anonymous Form" was not turned on.
  
  A quick search for the "Anonymous Form" on the Web pointed me to the IBM on-line documentation for Lotus Notes and Domino 8. According to this publication, anonymous forms are NOT supported on the Web... (?!?!):
  
  
  
  I didn't give up and decided to contact IBM Technical Support to see why. Their answer was a bit surprising, because according to the reply I got, this feature IS actually supported but an extra step needs to be taken by a developer in order for this to work the same way on the Web as it does in Notes:
  
  "After researching our source, I found one alternative approach we can adopt to circumvent this issue. We can force the HTTP task to honor the "Anonymous Form" setting by explicitly creating a text field named "$Anonymous" in your form ("Anonymous Form" setting should be checked) and setting it's default value to "1" (text)."
  
  It works!
  
  I was informed that this issue have been reported to IBM's quality engineering for further analysis in SPR# PCHE83KQTL. I asked for a new technote on this to be created, since I was unable to find one, and I was told one is being created. I will update this post once I know the technote number.
  

Posted by Bodek Frak At 03:40:52 PM Location Windsor - U of W | Permalink | Comments (16) | TrackBacks (0)

Category Lotus Notes and Domino Issues
Bookmark :              

IBM released FP4 for Domino and Notes 8.5.1 on August 5. After downloading it and trying to get it installed on three of our Domino servers, I run into the same issue on each one of them. It takes about 5 minutes for the installation, until it gets to the last stage. It first shows that it is 100% finished (fig 1), only to jump to the next screen that says "Updating patch information" (fig 2). It goes south from there..., on the last server it took about 1 hour and 25 minutes for the top progress bar to move from 30% to 100%. I tried Googling "Updating patch information" but did not find any hits yet... Is it just me?

Posted by Bodek Frak At 09:44:02 AM Location Windsor - U of W | Permalink | Comments (0) | TrackBacks (0)

Category Lotus Notes and Domino Issues
Bookmark :              

Recently, we had a serious failure of one of the three Domino servers in our cluster. We had to move people to another server using "Move to Another Server" tool in Domino Administrator 8.5.2. Later, we had to move them back, and we took this opportunity to split all our user's population evenly between the three servers in the cluster. In the end, we used this tool on every one of our 2,917 users.

Once I updated their home server assignment using Domino Administrator, the next time they log into Notes, a process called Dynamic Client Configuration runs on the client and it supposed to update their location settings to match those in Domino Directory. Around the same time we changed people's home server assignment, we started getting reports of users being unable to run Notes because they were getting "Warning: unexpected MIME" error on start-up, and when they clicked "OK", Notes would shut down. We run Notes and Domino for 10 years+ here, and I never encountered this error message before. Thanks to Andy's blog post "Another Weird MIME Error", I was able to quickly determine that the culprit was a corrupted location document. Unfortunately I was not able to find a relevant IBM's technote on this...

I suspect that for some reason the Dynamic Client Configuration process may be corrupting user's active location document in some cases. The good news is, that I used this tools to update 2,917 users, and so far the number of calls related to this issue is less than 10. That's less than 0.3%.

Posted by Bodek Frak At 10:24:49 AM Location Windsor - U of W | Permalink | Comments (0) | TrackBacks (0)

Category Lotus Notes and Domino Issues DAOS
Bookmark :              

Help file in Domino Administrator 8.5.2 says:

"Minimum size of object before Domino will store in DAOS : The minimum total size, in bytes, of any attachment to be consolidated (the default is 4096 bytes). Enter a number. Consolidating attachments of very small size is not worth the processing effort because it does not yield much disk space saving."

4096 bytes is 4 Kbytes, and that's what we have used to configure DAOS on our servers from its introduction in release 8.0. However, after installing one of the maintenance releases on the server (currently at 8.5.2FP2 on AIX 5.3 64-bit), it now displays this message on the console after starting up:

"Warning: DAOS object minimum participation size = 4096, which is below the minimum recommended value of 64000".

After some digging, I discovered that the help file fails to mention that the default value in this case is not the recommended value (ie. not anymore). That's a bit odd, because usually you want your default to be the recommended value. In this case, the default value is the minimum allowed value, according to the Notes and Domino Wiki entry on DAOS:

"“Minimum size of object before Domino will store in DAOS” (bytes): The default is 4096. 64,000 is recommended."

I contacted IBM Tech Support on this, and this is what they told me:

"Originally the recommended minimum size to use for the 'Minimum size of object' was 4096 bytes, however in later releases this has been increased to 64000 bytes as it was found that in most cases the gains from storing such small attachments was not enough for the processing required. So, for your version of Domino the recommended value for this setting is "64000" and the help file is out of date at this time. Also, please note that this value is set in bytes, meaning that 4096 bytes equates to 4KB,  similarly 64000 is for about 64Kb attachments. "

Note the "about" before "64Kb" because it's 4096 bytes that comes to exactly 4 Kbytes, while 6400 bytes comes to 62.5 Kbytes, if you are using 1 Kbyte = 1024 bytes conversion factor. If one wants to go for exactly 64 Kbytes limit, then the actual number would be 65536 bytes.

We used DAOS from the day it was introduced and we went with the original default/recommended value of 4096. Back then, enabling DAOS gave us some very good results (see my original "DAOS Rocks!" post), and I guess we were lucky not to get any noticeable performance degradation resulting from setting our  minimum size of DAOS attachments to such a small number (as per today's updated recommendations).

Recently, we had to temporarily disable DAOS on two of the three mail servers in the cluster so that we could copy all mail files to another server at the OS level. This gave me another opportunity to compare the "before" and "after" DAOS numbers. This time we went with 1 Mbyte limit for DAOS inclusion (ie. 1048576 bytes), instead of the original setting of 4 Kbytes (4096 Kbytes), and later lowered it to 0.5 Mbyte (524288 bytes).

smail:  552 files (shared mailboxes)
mail: 2,943 files (personal mailboxes)

File system		DAOS off, all attachments stored inside NSFs		DAOS on, with 1 MB limit		DAOS on, 0.5 MB limit
path	total allocated	free	used	free	used	free	used
/opt/lotus/notesdata/mail	707,788,800	163,260,780	544,528,020	334,571,836	373,216,964	376,573,016	331,215,784
/opt/lotus/notesdata/smail	63,963,136	14,276,104	49,687,032	27,849,784	36,113,352	32,015,724	31,947,412
/opt/lotus/DAOS	340,787,200	340,734,816	52,384	253,309,740	87,477,460	228,316,596	112,470,604
TOTAL (Kbytes)			594,267,436		496,807,776		475,633,800
TOTAL (Gbytes)			567		474		454

These results show that by setting the minimum size of DAOS attachments to 1 MB, we recovered 93 GB of space. By lowering the limit to 0.5 MB, we recovered additional 20 GB.


More Info on DAOS:

DAOS Best Practices - Optimum Minimum Size For Participation
http://www-10.lotus.com/ldd/dominowiki.nsf/dx/daos-best-practices#Optimum+Minimum+Size+For+Participation

Posted by Bodek Frak At 11:40:57 AM Location Windsor - U of W | Permalink | Comments (2) | TrackBacks (0)

Category Lotus Notes and Domino Issues Just Venting
Bookmark :              

I just LOVE to try all the new stuff that gets added to each maintenance release of Lotus Notes. It makes me feel like a kid opening Christmas presents. I savour and enjoy each one of them. And I appreciate the effort that the IBM put into improving their product and listening to the feedback from their customers. I really do. But I also hate when I discover that some things that were available in previous versions are no longer working properly, or worse, have been removed purposely without any notice or fair justification. Especially when it is something as useful  as the Screen Capture tool built into the Sametime Contacts pane in the Sidebar, which I was using practically every day, I was very disappointed to find out that after upgrading my Notes client to the latest 8.5.3, this tool is no longer available to Sametime Entry users. The icon for it is now greyed out, just like the icons for sending files, sending broadcasts, inviting to a meeting room, and inviting to instant meeting (which they were from the beginning).


Fig. 1 Sorry to say this, but this screen capture was taken using Microsoft Windows 7 Snipping Tool.

Yes, I know. If we get the full version of Sametime, I can continue to enjoy this wonderful feature. But we are not getting it. It's something beyond my control, which just adds to my desperation. We have been using Sametime Entry ever since it was released and bundled/integrated with the Notes client. That is since the release 6.5 in 2003. For eight years the Screen Capture tool was there and available to the Sametime Entry users like me. Not anymore.

I contacted IBM Tech Support to get an official answer on this back  in November, although I suspected I knew what the answer will be. Sadly, I wasn't wrong.

IBM: "I got a response from dev about a similar PMR, and unfortunately the change is most likely fixing a "bug" where the screenshot button was not greyed out in situations when it was supposed to be."

Me: "I will be honest with you and tell you that this makes some of us here very upset. I was fearing this scenario, and it seems like it came through... I think that it is a really bad move on behalf of IBM that you effectively take away something that has been made available for many years! It does not matter that this tool was made available to Sametime Entry users unintentionally, you should not make the users to pay the price for IBM developers' mistake. If the goal was to alienate many loyal long-time users and supporters of Lotus Notes like me, then MISSION ACCOMPLISHED! But is it really what IBM-Lotus needs these days? "

IBM: "I understand your frustration, and I will pass your comments along to my manager. Thank you for using IBM Lotus Support."

Sorry for being so negative, but things like this really get to me. There. I got it off my chest. Now, let's focus on something positive, like Lotusphere 2012 and the announcements that will surely come with it. Can't wait! I'll be there...

Posted by Bodek Frak At 01:31:18 PM Location Windsor - U of W | Permalink | Comments (2) | TrackBacks (0)

Category Lotus Notes and Domino Issues
Bookmark :              

If you are getting this error message: "Either the Server Controller is not running on host <server name> or is not listening on port 2050" and and you know that the controller is running, then most likely you have more than one NICs installed on your Windows 2008 Server.



In our case, we have two: one for client-server traffic, and one for server cluster replicator traffic. The order of these in Network Settings makes a difference. Network services on the server will access them in the order listed in Advanced Settings. On our server the cluster Network NIC was listed first and the error message stopped coming up as soon as I moved our main interface to the top of the list.


To change the sequence of the network interfaces do the following:

• Go to Control Panel
• Open Network and Sharing Center
• Click on Change Adapter Settings
• Press "Alt" key to see the menus
• Selects  "Advanced Settings..." from "Advanced" menu
• Review the order of your network adapters on the "Adapters and Bindings" tab.
• Put your main network interface on the top of the list and click OK to save the changes.

We also encountered another issue related to the incorrect order of network adapters on this list. When HTTP task was starting on the server running Domino 8.5.3FP1, it would bind to our Cluster Network interface rather than our main network interface. This is despite the fact that we added these line to the notes.ini and had all ports correctly defined in there.

PortOrder=TCPIP,CLUSTER
HTTPNotesPort=TCPIP
SERVER_CLUSTER_DEFAULT_PORT=CLUSTER

At the time, we solved the issue by listing the IP number of the main interface in the host name field (in addition to the host name) of HTTP task in server document with "Bind to host name" enabled. After adjusting the interface sequence, I was able to remove the IP number for that field, and after restarting HTTP task I noticed that it now binds to the correct interface.

Posted by Bodek Frak At 12:30:17 PM Location Windsor - U of W | Permalink | Comments (0) | TrackBacks (0)