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
  • Comments:

    1. Stop rushing the development, finish it before it gets out the door before you finish what is left of Novell's reputation.

    2. XML?! Really?! XML is the answer to the question that nobody asked. I can see it now, instead of a nice GUI view designer we are stuck with, edit this monstrous right weighted tree of garbage, save it, try to open the new view only to have crash and burn because one of what I can only imagine will be thousands of different badly named and confusing tags, got missed and there will be no feed back to tell you which one didn't work.

    3. No gui install for the Linux back ends. Uhm, let me guess, you have to do some rpm install then try your best to track down a bunch of text config files that some brain dead engineer scattered all over the hard disk, or having to edit some huge answer file that is both barely documented and laid out like some god forsaken XML file.

    4. "This change will affect the POA, MTA, GWIA, DVA, DCA and the new Web Administration Service." Hmmm I thought you said each component will have a micro html server built in? I guess not, so we get some monolithic all, browser all the time thing that if it dies we no longer have control over our groupwise system. Have you guys nver heard of the KISS principle?

    5. REST - OMG really? So there we go, 900 lines of text, flowing all over the place to extract 10 bytes of data. You guys are beyond belief. The system will be pushing text CRUFT at a rate of 1000 byes of markup CRUFT to 1 byte of actual data to do anything. Excellent move fella's. I guess the idea of binary API's that you can link to actual programs is to scary for you guys? So now if anyone wants to write programs that do anything useful they have to first write a program that can parse the millions of lines of text CRUFT that will be required to be spewed back and forth.

    6. An IDM driver AFTER the product is released?! Really?! What as service pack 1 6 months later, in the meantime I guess we will all just ignore Windermere until it comes along. EXCELLENT sales strategy guys!

    Really, you are going to try and push this software out the door in this completely sorry level of disarray? Ray is spinning in his grave so fast he is drilling a hole through the planet.

  • in reply to MigrationDeletedUser
    1) Agree, but I'm sure Novell is doing that already
    2) Great with XML, instead of a locked down old gui tool. With XML, we can do everything
    3) No problem with the installer been text-mode only, since all my GW servers are running runlevel 3 anyway, so IMHO, why waste resources on unneeded GUI
    4) I think Dean is talking about installing the agents, not managing them afterwards
    5) GW has been using SOAP with huge success for some time now, and 3.Party Devs as well. Moving the Admin API to REST, is even better, due to smaller overhead compared to SOAP, and by moving the Admin API to a web-based one, we finally can create solutions, that does not depend on a windows box, with both Novell client and GW client installed, as well as the fact, that GW will become directory independend, like in the very old days
    6) Yep....that kinda sucks, that you have to leave one IDM based domain around on GW12, just for that, but if that's what it takes, I'm fine with that
Comment
  • in reply to MigrationDeletedUser
    1) Agree, but I'm sure Novell is doing that already
    2) Great with XML, instead of a locked down old gui tool. With XML, we can do everything
    3) No problem with the installer been text-mode only, since all my GW servers are running runlevel 3 anyway, so IMHO, why waste resources on unneeded GUI
    4) I think Dean is talking about installing the agents, not managing them afterwards
    5) GW has been using SOAP with huge success for some time now, and 3.Party Devs as well. Moving the Admin API to REST, is even better, due to smaller overhead compared to SOAP, and by moving the Admin API to a web-based one, we finally can create solutions, that does not depend on a windows box, with both Novell client and GW client installed, as well as the fact, that GW will become directory independend, like in the very old days
    6) Yep....that kinda sucks, that you have to leave one IDM based domain around on GW12, just for that, but if that's what it takes, I'm fine with that
Children
  • in reply to MigrationDeletedUser
    1. Don't bet on it.

    2. Sorry an "old" GUI tool, when written correctly will run on any client. I f something is not yet broken that just means you haven't thrown enough XML at it yet. Sorry, these kinds of tools are meant to be visual as it describes the layout of the new view, so why use something that is both incomprehensible ( after it grows to more then one screen ) and so completely brittle as XML. As I asserted it is the answer to the question that no one asked and has been proven to be perfectly horrible at almost everything.

    3. Running in level 3 is fine. You can run X when you need it, then put it away when you don't. As to wasting resources, if your machine cannot run X for the hour it takes to install something, it has no business running GW.

    4. I will believe that when I see it.

    5. Perhaps for running a blog it is fine, but it is a horribly broken paradigm for just about anything else and it is an artifact of the completely and utterly inane lengths that a completely incompetent group of idiots have gone to to try and make a text markup and display system into an application container, the kludges simply trip over themselves constantly.

    The result of this is the pervasive and corrosive misuse of a technology that it cannot, and in point of fact and the definition of REST is that, it should never have any notion of state of the device it is communicating with. Yes that is exactly what you don't need when managing critical systems and the lengths that programmers have had to go to because some PHB and brain dead manager decide that this is just the "coolest" is really just over the top. As to your "We can finally..." all I can do is lay the blame squarely at the feet of Novell. Myself and hordes of others have begged them to update the API's, open up the server level API's. To update the client side API's so that they did not require OLE automation, just C or C++ bindings that would allow us to write clean FAST, SMALL, TIGHT tools to integrate things. You want to know why we got our collective asses handed to us by Microsoft? Because Novell either didn't see or didn't care about the integration train coming down the tracks. I lost more clients because it was insanely hard to try and write third part tools and for BIG vendors with lots of development talent to integrate their products with GW. Accounting software and I am talking about the software that runs accounting firms, for audit, tax prep, etc. MS made it EASY to hook into their e-mail software, calendering, etc. Novell could not be bothered. I watched for years as they did nothing to modernize the main API's. So now we have a text based 1000 to 1 cruft to data ratio interface that requires programs to parse all this cruft instead of making a C or C++ or C# call to fetch the data required or to create mail, appointments, reminders, etc. Oh how we have failed on so many levels in so many ways.

    6. someone go and grab the dev manager, choke them hard and scream at them FIX THE SOFTWARE BEFORE IT GOES OUT THE DOOR.

    Your millage may very.
  • in reply to MigrationDeletedUser
    1) Nobody can predict everything, but I'm sure that Novell is doing their best
    2) Regarding the viewer, did you ever notice how limited it is.......Novell is letting go now, and finally, we can start to take custom views where they are supposed to be, IMHO
    3) I wasn't talking about if the server could run on runlevel 5 or not, I was merely talking about why do twice the work, if not needed. If you really need a GUI for installing something on a Linux box, then I can only suggest training, instead of Trolling!
    4) I believe in both Groupwise and the Team behind it ;-)
    5) I partially agree on the fact, that a C or C++ API would be nice for fast code, but considering the fact, that Admin related work doesn’t have to be fast, and we now finally are getting cross-platform interface, that even will work on a tablet etc, I fail to see your point.
    6) I'll relate this to Item 1

    /Tommy
  • in reply to MigrationDeletedUser
    Everyone's input and feedback is valuable. Not every comment or suggestion warrants an answer or reply from me. So I will just simply let this discussion ride....

    Dean
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.