This is part 3: As plans, decisions and schedules are finalized regarding Windermere – there are several things to share and socialize in order to help you and your organization move forward with Novell and GroupWise.
Windermere is the next major release for GroupWise. It is expected to release in 2013. The focus is on replacing ConsoleOne with a new web administration console, expanding directory support to include Active Directory, and updating the look of the Windows Client. There are also several strategic and forward looking decisions to consider. Through a series of blog posts or related cool solutions articles, these topics will be introduced and socialized. Please review and respond so that considerations are included and potential impact and trade-offs are debated.
Note: This particular blog series…part 1 through part 3…is not intended to be a feature list for Windermere. You should not assume that because it is not discussed in this series, that your particular request or feature will not be included in Windermere. This series is only to discuss some of the technical dependencies that will be created by changes happening in Windermere. We want to socialize and share this information in order to help your company or organization prepare its systems, data centers, servers, desktops, and processes for Windermere.
In this blog, a discussion regarding the transition from ConsoleOne to the new Web Adminstration console will be discussed. If your organization is small enough that you only have 1 or 2 GroupWise servers and that you normally upgrade from version to version in one single movement, then this topic may not be salient for you. However, it is well understood that most large organizations can not upgrade their entire GroupWise system simultaneously or in one evening or weekend. Therefore, for many organizations they will upgrade and utilize the new Windermere tools to administer the upgraded portions of their GroupWise system while maintaining and utilizing ConsoleOne for all agents that are still running on previous versions of GroupWise and waiting to be upgraded.
Here are several points to consider and remember and then we anticipate that some of you may have specific questions that we can address or make sure engineering considers as Windermere is developed.
As with all version updates the primary domain must be updated first. Also, an owning domain must be updated before any post offices can be updated. This has long been a best practice and will continue to be in Windermere.
ConsoleOne NOT Supported on Windermere Agents
After a domain is updated, only the new Web Admin console can be used with upgraded domains and post offices. The Web Admin tool can be used to administer post offices or domains that have not been upgraded, but once the upgrade process begins, we HIGHLY recommend you are consistent with your administration tools. Meaning…if you have a post or domain that has not been upgraded, you can administer that agent using ConsoleOne OR the new Web Admin tool, but which ever tool you choose to use….ONLY use that tool until the agent has been upgraded. Do NOT switch between the tools to administer an agent that has not been upgraded and still has an object in eDirectory.
Once upgraded, you will no longer be able to use ConsoleOne and only the Web Admin tool can be used.
LDAP is required if syncing with an external directory. Access to LDAP should be configured when upgrading an existing system. This configuration will be part of the installation process in order to aid in the upgrade process. If you are not synching with an external directory, eDirectory, Active Directory, etc., then Windermere can be run completely stand alone and contained. In other words, no external directory is required. We expect most of our customers will continue to use eDirectory, since that is required with versions of GroupWise today. As a best practice, we recommend that you plan your external directory strategy before upgrading to Windermere. If you plan to continue to use an external directory, then you should make sure you are prepared to provide LDAP access to that directory and proper planning, access and versioning is considered.
All access to the external directory will be through LDAP. GroupWise Windermere does have minimum server and OS requirements, but those requirements to not apply to the server that is running your directory. Minimum eDirectory requirements will be eDir 7.x and later. Most versions of Active Directory will also be supported. Currently, we plan to recommend the versions of Active Directory that come on Windows 2003, Windows 2008 and Windows 2012 server.
New System Administrator Account
During the upgrade process a new System Administrator Account will be provisioned. Prompts for credentials for this account will be required for this new system administrator account. We will no longer be using eDirectory for any rights checking. The new system administrator account can grant rights to other users but it must be defined first.
New domains and post office created with Windermere will not be created in eDirectory (or any external directory). This causes a few side effects. First, ConsoleOne will not run against a domain if there is not an associated eDir object. Therefore, ConsoleOne is not supported at all with any Windermere created domain or post office. Second, the current Admin API handles stand-alone domains properly, but any users in those domains that have a distinguished name defined will be ignored. Novell is beginning an SDK/ISV beta in the coming weeks. We will be working with all of our partners and 3rd-party solution providers so that they can make appropriate adjustments in their products and recommend upgrade paths and best practices. We will communicate via our partners, this blog and other communications to help socialize any appropriate Partner solutions changes.
Once again, it is HIGHLY recommend that you remain consistent during the upgrade process with each domain and post office. If a post office or domain exists in eDirectory, you can still manage it using ConsoleOne. If you choose to do that – you should ALWAYS do that until the post office or domain is upgraded.
We will not be creating External Entity objects in eDirectory anymore. They were only needed to simplify administration with ConsoleOne. The Windermere Web Admin Console can handle users not linked to any external directory fine so External Entities do not seem to have a need any longer. Existing external entities can remain in place. We will continue to sync them but the new Web Admin does not support creating new external entities.
Browsing and Relative Paths
With the changes in Windermere, administrators should set paths for domains, post offices, etc. from the perspective of the Admin Service. In other words, since the admin service runs on the same machine as the agents then paths should be from the perspective of the service and not from the perspective of the admin's workstation. Today, since ConsoleOne runs on the admin's machine/desktop most paths are from that perspective. That will be changing to look at the world from the view of the Admin Service.
Note: Browsing for files can be done from either the perspective of the workstation or the admin service.
More and more of our end users are accessing GroupWise via IMAP. This is principally from mobile devices, but also from a variety of other desktop clients. Engineering has identified several optimizations and changes in the way the IMAP Agents (POA and GWIA) process IMAP requests in general and specifically regarding a couple of IMAP caching defaults. These changes are being made in an effort to improve performance and end user experience. First of all, we will default the IMAP Read Limit to 10K max messages at a time and, by default, read in items from newest to oldest. These changes replace the old defaults of 20K max messages and reading in items from oldest to newest. By making these changes we believe end users will continue to be able to get the messages they are most concerned with and will see an increase in performance and memory usage on the POA and GWIA at the same time. This is a change in default behavior, however, and could impact some of you and your users. You will still be able to override the maximum read limit default by using the IMAPREADLIMIT switch (up to the already existing ceiling of 65K messages). A new switch IMAPREADOLD will allow you to revert to the old behavior of reading items in from oldest to newest. The IMAPREADNEW switch will no longer be needed.
Engineering will also change the memory management model that the IMAP agents use. The new caching model will allow the IMAP agents to better manage allocated memory between multiple connections. These memory changes will be transparent to the end user. In addition the data that is being read from the user databases is being optimized to further minimize memory usage and speed up response time. End users should see an increase in the performance and a quicker response time for 15 different IMAP commands.
This is the last blog submission in this series. Please read parts 1 and 2 in conjunction with this blog to see a comprehensive view of the technical dependences required to upgrade and run Windermere. After BrainShare, the GroupWise blog will publish a more comprehensive list of new features and enhancements that are committed for Windermere. We will expand on that list as capabilities are finished in the product and any new capabilities are added. The Windermere project plan is set and the Product Requirement Document and Platform Support documentation is complete. As work is completed, there may be opportunities to add additional features, but they will not be listed or committed to in the original blog post.
Please submit your questions and concerns and individual scenarios so that everyone benefits from your input and feedback.
Thanks – Dean
GroupWise: Windermere Changes Series: