Related Tips & Info
Wikis - Page

GroupWise: Windermere Changes – Part 4

MigrationDeletedUser
0 Likes

This is part 4. 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.

I thought we were done with a three part series, but it looks like we have a few more points to discuss and share with you. I would like to say this will be the last such blog submission, but I don’t want to be called a liar when we end up doing a part 5. I guess we will just have to see.

Note: This particular blog series…part 1 through part 4…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.


Below, you will find a few more topics highlighted that we have made specific technical decisions around. Please let us know if you agree or if you think we have missed something critical in our analysis, understanding or evaluation of our customers or the market.

IDM Driver


Novell will release a new IDM Driver with GroupWise Windermere. The current plan has the Windermere IDM driver releasing shortly after Windermere is available. Communication about options for organizations who are currently using the IDM driver and background information on what is changing is provided here.

Background

Currently, the GW 2012 code checks for eDir rights. As you already know, Windermere GroupWise will not create directory objects so these missing directory objects cause issues for the 2012 code that expects them. There are a variety of internal and external solutions that may rely on the existence of these objects in order to function properly. This includes solutions from our partners. For some partners, they may not have completed porting existing Admin OAPI solutions to the new Admin RESTful interface. In addition, the mechanism for locking out older versions of ConsoleOne will also lock out the IDM driver.

Running ConsoleOne will not be supported on Domains and Post Offices that have been upgraded to Windermere. However, no lockout mechanism will be provided since it would also lockout the existing IDM driver.

The Admin API, IDM driver and ConsoleOne will fail when running against Windermere under certain scenarios. Customers will have to wait for a REST based IDM driver to be made available. Customers will need to wait for partners to provide REST based solutions. Engineering is not planning on updating the GroupWise 2012 or GroupWise 8 based IDM driver to address failures. The solution will be to upgrade to the Windermere version of the IDM driver when it becomes available. Engineering is also not providing an update to the Admin Object API to be backward compatible for 3rd-party solutions. 3rd-Party solutions will need to convert their solutions to run with the new Admin RESTful interface. Communications and planning with our partners and a partner BETA for Windermere has already begun.

Here are a few scenarios that help illustrate a few of the issues we anticipate and the solution or recommendation provided

    • Scenario 1: An upgraded system where no domain has been modified (still has a tree name), and the user object has not been modified (still has a DN)
      Result: Older solutions should continue to run, but may not be officially supported (e.g. ConsoleOne)



 

    • Scenario 2: An upgraded system where the domain has been modified, and a user object is not associated with a directory
      Result: Older solutions should continue to run, but may not be officially supported (e.g. ConsoleOne)

 

    • Scenario 3: An upgraded system where a new domain is created (no tree name) and users with a DN have been moved to that domain or do not yet exist
      Result: The administrator will not be able to add new users with old code (ConsoleOne snap-ins). IDM will have the same issue as ConsoleOne and it is all related to the Admin OAPI: therefore, users will not show in query results and administrators will not be able to add new users.

 

    • Scenario 4: An upgraded system where a new domain is created, and a user without a DN exist in the domain
      Result: Admin Object API seems to work properly Console One and IDM will not run.



 

A command line script will be provided as a sample SDK app that can remove the DN from GroupWise user objects based on the value of the owning domain's tree information and/or a script to remove both the Domain tree info AND users DN info to move systems to a scenario 4 state. Engineering recommends this script NOT be run if the IDM driver is also configured. For customers not using IDM that utilize Admin Object API based solutions the script *may* improve their experience until those solutions can be rewritten to REST.

Summary: Customers that rely on Admin Object API based solutions or that use the GW IDM driver should consult with Novell before upgrading to Windermere.

View Designer


The View Designer and the capability that it provides will be discontinued in its current form in Windermere. An updated View Designer will not be provided for Windermere. The GroupWise Windows Client views will begin a transition in Windermere from the View Designer technology to an XML based solution. This transition is expected to carry beyond the Windermere release.

In the future, all GroupWise views will simply be XML based definitions that can be edited using any XML editor.

Web Administration via your Tablet


For the Windermere release, we will initially support Apple iPad1, iPad2 and iPad3 and iPad mini. Additional tablet support will come as we move forward.

The discussion on the scope of validation required to issue a support statement for tablet devices being used to run the new Web Administration Console has been fun! As we evaluated how any Web application is rendered and how best to support Web Administration on as many devices/tables as possible, we made the following choice.

For Web Administration using a tablet, we will only officially support pixel widths of 1024 and greater and pixel heights of 600 and greater. While lower resolutions will effectively work, there may be screen anomalies, repainting artifacts or other annoying user experiences. Note that this willl affect the first three generations of iPhone (480x320), and both the iPhone 4 and iPhone 4S (960x640). It will however pick up the iPhone 5 and next generation iPhones to come. We may decide to officially support other resolutions for Windermere SP1.

Given the information/decision, here are the tablet resolutions that we will be supported.

2048x1536:

    • Apple iPad 3

 

    • Apple iPad 4



1920x1200:

    • Asus Transformer Pad Infinity (TF700T)



1366x768:

    • Lenovo IdeaTab Lynx



1280x800:

    • Samsung Galaxy Tab 8.9

 

    • Samsung Galaxy Tab 10.1

 

    • Samsung Galaxy Tab 2 (10.1)

 

    • Samsung Galaxy Note 10.1

 

    • Asus Eee Pad Transformer (TF101)

 

    • Asus Eee Pad Transformer Prime ( TF201)

 

    • Asus Transformer Pad (TF300T)

 

    • Asus/Google Nexus 7

 

    • Lenovo IdeaTab S2110

 

    • Lenovo IdeaTab A2109



1280x720:

    • Samsung Galaxy Note II (5.55" smartphone)



1280x600:

    • Samsung Galaxy Tab 7.7



1136x640:

    • Apple iPhone 5 (Smartphone)



1024x768:

    • Apple iPad 2

 

    • Apple iPad,

 

    • Apple iPad mini,

 

    • Lenovo IdeaTab S2109



1024x600:

    • Samsung Galaxy Tab (7-inch)

 

    • Samsung Galaxy Tab 7.0 Plus

 

    • Samsung Galaxy Tab 2 (7-inch)

 

    • Lenovo IdeaTab A1107

 

    • Lenovo IdeaTab A2107



Linux Agent Install


We have decided to streamline the Linux install for the agent or server components. There will not be a GUI install for Linux. The Windows agent/server install will continue to have a GUI based install. Linux, however, will more closely match how components and software are deployed and installed on this platform. We will also remove the dependency on python libraries on the Linux agents install. This change will affect the POA, MTA, GWIA, DVA, DCA and the new Web Administration Service.

Thank you for continuing to read, provide feedback and ask clarifying questions regarding Windermere. As you should be able to tell, Product Management and Engineering are taking a bigger step forward with Windermere in order to set our product, technology and customers on more sure footing and prepare them for the ever changing landscape ahead. We hope you understand the changes we are making and while there may be some pain associated with these changes for some customers, we certainly believe that all customers will benefit.

As always, please submit your feedback for all to see so that all can benefit.

Dean

 

Tags:

Labels:

How To-Best Practice
Comment List
Parents
  • Dean, love the idea of going with just a text based installer on Linux. Best practices say to disable the GUI on Linux anyways. However, now that Microsoft is starting to follow this example by making Core installs the default installation pattern on Server 2012, are there any plans to allow for non-GUI installs on Windows and supporting Windows Core?
  • in reply to MigrationDeletedUser
    Great question!

    This is not currently planned for Windermere, but is something we will evaluate and comply with as we move forward.

    Dean
  • in reply to MigrationDeletedUser
    Hey Dean,

    I have no problem with text based installs. In fact I prefer them!

    Now let me qualify that. Netware used a text based install for most of its life. In fact even YAST has a text based version, no GUI required; however, those programs use a nice CUI that handles things reasonably well since they do actual screen positioning and have as of late even begun to use some function keys.

    My main thrust here is to implore you guys NOT to go the classic RPM or DEB route, UNLESS you slap some developers around and get the config files all in one place. I humbly suggest someplace like, ohhhh the /etc directory. Heck it could even be nicely setup so it was say:

    /etc/grwpwise/gwia
    /etc/grwpwise/poa
    /etc/grwpwise/mta
    /etc/grwpwise/web
    /etc/grpwise/...

    That is a preferable way to do things I think all would agree.

    Another problem is that you guys have stripped a lot of the useful parts of the admin side of Group Wise and things become harder to troubleshoot and deal with. The console screens for Group Wise on Netware were fantastic tools to see what was going on in ( as close as you could get ) real time with your system.

    Now I realize that Linux is a different paradigm from Netware. What I was hoping for ( desperately ) was that you guys would strip out ALL of the GUI support and then run each of those in a separate Alt-F1...Alt-Fn space, including something that resembled Monitor, where you could see in ( as close as you could get ) real time what your system was doing by emulating the TOP program or IOTOP or say the PS command all in one place.

    That was the kind of innovation and intelligence that I had come to expect from Novell. Could you build out some web services for those people who cannot handle ssh connections, or using a tool like screen sure, but for those of us who are administrators we can do those things and I think that should have been your target audience.
Comment
  • in reply to MigrationDeletedUser
    Hey Dean,

    I have no problem with text based installs. In fact I prefer them!

    Now let me qualify that. Netware used a text based install for most of its life. In fact even YAST has a text based version, no GUI required; however, those programs use a nice CUI that handles things reasonably well since they do actual screen positioning and have as of late even begun to use some function keys.

    My main thrust here is to implore you guys NOT to go the classic RPM or DEB route, UNLESS you slap some developers around and get the config files all in one place. I humbly suggest someplace like, ohhhh the /etc directory. Heck it could even be nicely setup so it was say:

    /etc/grwpwise/gwia
    /etc/grwpwise/poa
    /etc/grwpwise/mta
    /etc/grwpwise/web
    /etc/grpwise/...

    That is a preferable way to do things I think all would agree.

    Another problem is that you guys have stripped a lot of the useful parts of the admin side of Group Wise and things become harder to troubleshoot and deal with. The console screens for Group Wise on Netware were fantastic tools to see what was going on in ( as close as you could get ) real time with your system.

    Now I realize that Linux is a different paradigm from Netware. What I was hoping for ( desperately ) was that you guys would strip out ALL of the GUI support and then run each of those in a separate Alt-F1...Alt-Fn space, including something that resembled Monitor, where you could see in ( as close as you could get ) real time what your system was doing by emulating the TOP program or IOTOP or say the PS command all in one place.

    That was the kind of innovation and intelligence that I had come to expect from Novell. Could you build out some web services for those people who cannot handle ssh connections, or using a tool like screen sure, but for those of us who are administrators we can do those things and I think that should have been your target audience.
Children
No Data
Related
Recommended

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.