GroupWise: Windermere Changes – Part 3


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.

Primary Domain

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

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.

External Entity

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.


IMAP Changes

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.

The end....

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:

    • GroupWise: Windermere Changes – Part 1


    • GroupWise: Windermere Changes – Part 2


    • GroupWise: Windermere Changes – Part 3


    • GroupWise: Windermere Changes – Part 4


    • GroupWise: Windermere Changes – Part 5




How To-Best Practice
Comment List
  • In the New groupwise 2012 sp2 I cannot find an Web Admin Tool in the documentation only ConsoleOne. But you Write about a New Web Admin Tool , Where is this?
  • "We will not be creating External Entity objects in eDirectory anymore. They were only needed to simplify administration with ConsoleOne." -- we have a third-party mail filter appliance which uses an LDAP lookup to validate the recipient's address before passing the message to GWIA. How will external entities be validated if they're no longer in the (a) directory?
  • in reply to MigrationDeletedUser

    We do plan on the ability to Graft. This process will match up users and should do what you are asking. Alternatively, we could certainly provide a utility to do this. The utility may not be part of the product, but become a Cool Solution or provided another way.

    For the most part, this is a use and discard type of utility and so would not necessarily be included as part of the product.

  • in reply to MigrationDeletedUser
    Thanks for the clarification. I'm sure this isn't in the pipeline now, but it would be nice to have some kind of tool that will do a mass association. So in other words, it will search AD for users with the same username as GW and link them. Is that possible? From what I read, I will have to click on each user to re-associate to AD. With 6000 users I'm not sure that's practical.

  • in reply to MigrationDeletedUser
    From Engineering:

    We will have Disassociate/Associate process so they can select an existing GroupWise user, disassociate that user with an eDir user and associate them with an AD user. A user can only be associated with one user object in eDir or AD. When we do the first sync we assume all objects are linked to an eDir user since that is all that is supported at this point. However, using the Windermere code they could disassociate a user from eDir and assoicate it with an AD user. We will support syncing users from eDir and AD in the same system. It also sounds like they want to move away from eDir but they need to be aware that IDM cannot be used to sync AD directly to GroupWIse.

    You will be able to create a GroupWise account for an existing eDir or AD user and that creates the user in the GroupWise domain database. You will also have the option to disassociate the GroupWise user from the eDir/AD account it is synced with and associate it with a different account to sync with. This operation can currently be done in ConsoleOne but only for eDir users.

    In Windermere we will use LDAP to associate GroupWise users with eDir and AD so you can pick from either one when performing a manual association.


  • in reply to MigrationDeletedUser
    The process will be something like ZCM ? Import user what ever the source (eDir or AD) and after that able to associate with an account already on the GW system.
  • in reply to MigrationDeletedUser
    Makes sense now.

    Thanks !
  • in reply to MigrationDeletedUser

    The first version will not have ODBC support. This is something we can consider for a future release as customer/partner demand supports it.

  • in reply to MigrationDeletedUser
    Additional Information:

    A single GroupWie system can contain users from both eDir and AD at the same time. The process of associating users will be similar to the Associate/Disassociate process in ConsoleOne.

  • in reply to MigrationDeletedUser
    Additional information:

    The Admin Service provides the rebuild ability so the Admin Service on SERVER1 will communicate with the Admin Service on SERVER2. Since the Admin Service is installed wherever the agents are installed then the Admin Service running on SERVER3 (running in a limited post office-only mode) will also communicate with the Admin Service for it's owning domain to perform a rebuild.

    Make better sense?