You are using Microsoft Internet Explorer browser to schedule a Lotus Sametime Meeting and receive the following error:
"Cookies are not enabled."
This issue does not occur when using other browsers or versions of Internet Explorer earlier than version 5.5.
Lotus Sametime is working as designed. This error message is displayed when using Internet Explorer 5.5 and 6.0 or later with the Microsoft Patch MS01-055 (or a Service Pack that also includes this patch). When Internet Explorer is updated, it then becomes compliant with Request for Comments (RFC) 952, which defines and restricts host and domain naming conventions. This compliance is to avoid certain security vulnerabilities with session cookies, as explained in this Microsoft Knowledge Base Article #316112 excerpt:
The reason that the error message appears is that the cookie is never created by the browser. The RFC 952 document defines the proper syntax for a host/domain name.
"A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". (See RFC-921, "Domain Name System Implementation Schedule", for background). No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case.
Resolving the problem
Refer to Microsoft Support Articles 316112 and 149044 for more information about how Internet Explorer handles cookies.
You can use any one of the following workarounds:
- Change the fully qualified host name of the server so that it is compliant with the naming conventions defined in RFC 952.
- Create a URL/Redirection document so that users are redirected to servername.domain.com instead of server_name.domain.com.
- Change session authentication on the Server document's Internet Protocols tab/Domino Web Engine tab to Disabled. Because the Sametime Web Administration Tool requires Web SSO to be set to enabled (Single-Server or Multi-Server), you will need to implement a workaround as documented in "Sametime: Unable to Administer the Server when Web SSO is Disabled" (#1090310 ).