Sebastian Cerazy wrote:

> Now to even install the product I have to have beefy Windows server
> with IIS

Not exactly accurate. You can install it on say a Windows 7 desktop
for evaluation purposes, as long as it's Windows 7 64-bit. But yes for
a production environment, as of now at least, you need to install NFR 2
on 64-bit Windows Server.

--
Your world is on the move. http://www.novell.com/mobility/
BrainShare 2013 is coming! http://www.brainshare.com

Why would I evaluate product that I was using since FSF days?

64-bit is not an issue here.

What is, the fact that all my storage is on NSS volumes (so I can avoid need
for Windows servers storage), yet to administer it (and NFR is
administration tool) I need to have Windows server

Madness!

Seb

"Joseph Marton" <jmarton@no-mx.forums.novell.com> wrote in message
news:9PrUs.3725$vO3.2404@kovat.provo.novell.com...
> Sebastian Cerazy wrote:
>
>> Now to even install the product I have to have beefy Windows server
>> with IIS
>
> Not exactly accurate. You can install it on say a Windows 7 desktop
> for evaluation purposes, as long as it's Windows 7 64-bit. But yes for
> a production environment, as of now at least, you need to install NFR 2
> on 64-bit Windows Server.
>
> --
> Your world is on the move. http://www.novell.com/mobility/
> BrainShare 2013 is coming! http://www.brainshare.com

Sebastian Cerazy wrote:

> What is, the fact that all my storage is on NSS volumes (so I can
> avoid need for Windows servers storage), yet to administer it (and
> NFR is administration tool) I need to have Windows server

Yes, this has been a source of complaints from a few folks. The reason
this architecture change was made is for a couple of reasons. First,
the tools used to build the new NFR architecture allow it to be very
extensible. This means that reporting capabilities could be extended
beyond just NW/OES/Win and in fact we're currently investigating this.
This sort of extensibility does not exist with any sort of Linux-based
tools. Building all of these tools from scratch on Linux is something
that was looked at but that brings us to the second point. To do
something like that would have taken a great deal of time. NFR 2
wouldn't have been released this year and possibly not even for a
couple more years. In the meantime customers would have been faced
with the limitations in NFR 1's reporting capabilities while having to
wait and wait and wait for the next version.

We recognize that a Windows server is now required when in the past it
wasn't is a potential downside, but hopefully when looking at the
benefits of what's in NFR 2 today and where the new architecture will
go over the next 12-24 months those benefits will outweigh the downside
of requiring Windows server.

--
Your world is on the move. http://www.novell.com/mobility/
BrainShare 2013 is coming! http://www.brainshare.com

I have to agree with the original sentiment. While I understand the desire to extend the product to additional areas (and thus a back-end redesign) - it seems that the product has taken a great leap backward:
1. The requirement of a Windows machine (Server or 7)
2. The loss of multiple scans of a single machine held in the system for comparison
3. The significant loss of performance and scalability (I used to run this on OES2 VM with "minimal" specs that could process 4 TB/millions of file scans easily. Now I am unable to so far build a beefy enough system to even do basic tasks of this data without extreme lag or errors)

How hard would it really have been to recompile the code for a 64-bit OES11 environment of the 1.x version and do some minimal maintenance while at the same time working through these issues of version 2.x?

Personally I can't justify keeping this on my ALA anymore.

jmarton;2247502 wrote:
Sebastian Cerazy wrote:

> What is, the fact that all my storage is on NSS volumes (so I can
> avoid need for Windows servers storage), yet to administer it (and
> NFR is administration tool) I need to have Windows server

Yes, this has been a source of complaints from a few folks. The reason
this architecture change was made is for a couple of reasons. First,
the tools used to build the new NFR architecture allow it to be very
extensible. This means that reporting capabilities could be extended
beyond just NW/OES/Win and in fact we're currently investigating this.
This sort of extensibility does not exist with any sort of Linux-based
tools. Building all of these tools from scratch on Linux is something
that was looked at but that brings us to the second point. To do
something like that would have taken a great deal of time. NFR 2
wouldn't have been released this year and possibly not even for a
couple more years. In the meantime customers would have been faced
with the limitations in NFR 1's reporting capabilities while having to
wait and wait and wait for the next version.

We recognize that a Windows server is now required when in the past it
wasn't is a potential downside, but hopefully when looking at the
benefits of what's in NFR 2 today and where the new architecture will
go over the next 12-24 months those benefits will outweigh the downside
of requiring Windows server.

--
Your world is on the move. Novell. Because Your World is on the Move.
BrainShare 2013 is coming! IT conference | BrainShare 2013

jffgrnfld wrote:

> 2. The loss of multiple scans of a single machine held in the system
> for comparison

Some of that historical data should be in the database used by NFR 2,
and even when that data is gone there is still volume space info which
is kept for trending purposes. There shouldn't be any functionality
lost here--are your experiences different?

> 3. The significant loss of performance and scalability (I used to run
> this on OES2 VM with "minimal" specs that could process 4 TB/millions
> of file scans easily. Now I am unable to so far build a beefy enough
> system to even do basic tasks of this data without extreme lag or
> errors)

I know you posted in another thread about some scalability concerns.
The issues you reported shouldn't be happening. One thing NFR 2
supports is to run the Postgres database on Linux, and this may
actually give you better performance. There are actually three configs
you can run.

1) Postgres

>> 2. The loss of multiple scans of a single machine held in the system
>> for comparison
>
>Some of that historical data should be in the database used by NFR 2,
>and even when that data is gone there is still volume space info which
>is kept for trending purposes. There shouldn't be any functionality
>lost here--are your experiences different?

One of the main uses we have for NFR is to answer the question "where did the space go?". Volume space info for trending in NFR is somewhat crude (especially given the fact that you can get a fairly nice "available space" report out of NoRM with the history of the life of the server already out of the box). The key is to be able to run a comparison report between some point in time scans to compare the difference in files. With only one scan available to run against, this comparison functionality is lost.
And before you say that a report that looks at "recent" files is the answer - the problem there is that OES servers aren't consistent in their timestamps of files placed on the server between transport methods. NCP and SMB put the last modified date as the date placed on the server. AFP preserves the original date/timestamps of the source files, so you can place a "very old" file on the server and not have it show up in a report looking for recently added files. I've tried to raise this concern in multiple ways in the past as well.

>> 3. The significant loss of performance and scalability (I used to run
>> this on OES2 VM with "minimal" specs that could process 4 TB/millions
>> of file scans easily. Now I am unable to so far build a beefy enough
>> system to even do basic tasks of this data without extreme lag or
>> errors)
>
>I know you posted in another thread about some scalability concerns.
>The issues you reported shouldn't be happening. One thing NFR 2
>supports is to run the Postgres database on Linux, and this may
>actually give you better performance. There are actually three configs
>you can run.
>
>1) Postgres

On 2/18/2013 3:26 PM, jffgrnfld wrote:

>
> How hard would it really have been to recompile the code for a 64-bit
> OES11 environment of the 1.x version and do some minimal maintenance
> while at the same time working through these issues of version 2.x?
>
jffgrnfld,

Joe's responses to the rest of your concerns have been spot-on, but as
part of the support and testing team for NFR 2.0, I wanted to address
this specifically.

The short answer is that it would have been impossible to make the
existing codebase for NFR 1.x do what we wanted NFR 2.x to do. NFR 1 did
not use a database to store scan data. It had no concept of, and could
never have reported on, file system permissions. It was fundamentally
incapable of reporting on multiple identity systems at once (and the OES
Engine could never have interfaced with a Windows environment.) Even
something seemingly simple, like adding email notifications of completed
activity, would have been a major effort -- as much effort as writing a
new, enhanced, and extensible Engine.

Having the Engine on Windows is the only way the Engine can interface
with Active Directory (through Win32 APIs) *and* Novell eDirectory
(through NCP calls provided by the Novell Client) simultaneously.
There's simply no viable OES-to-Windows alternative. Likewise, the
consumable reporting system that NFR 2 uses is *only* available on
Windows. Not only did that reporting system let us get NFR 2 out in a
reasonable timeframe, but it also provides a backbone for advanced
reporting options and extensible reports.
--
- NFMS Support Team

So all in all (after reading all the post above) is it an overkill, no
matter how good/bad/slow/fat/scalable etc it might be

All I need (for now) is how many avi files exist in folder x, and how many
..mp3 exist in foler y
And how many file not touched in 365 days exist in folder z

This I might get with some Windows based shareware

NFR is coming off my Agreement next time round!

Seb

"Novell File Management Suite Team" <storagemanager_@novell.com> wrote in
message news:512394BA.5010001@novell.com...
> On 2/18/2013 3:26 PM, jffgrnfld wrote:
>
>>
>> How hard would it really have been to recompile the code for a 64-bit
>> OES11 environment of the 1.x version and do some minimal maintenance
>> while at the same time working through these issues of version 2.x?
>>
> jffgrnfld,
>
> Joe's responses to the rest of your concerns have been spot-on, but as
> part of the support and testing team for NFR 2.0, I wanted to address this
> specifically.
>
> The short answer is that it would have been impossible to make the
> existing codebase for NFR 1.x do what we wanted NFR 2.x to do. NFR 1 did
> not use a database to store scan data. It had no concept of, and could
> never have reported on, file system permissions. It was fundamentally
> incapable of reporting on multiple identity systems at once (and the OES
> Engine could never have interfaced with a Windows environment.) Even
> something seemingly simple, like adding email notifications of completed
> activity, would have been a major effort -- as much effort as writing a
> new, enhanced, and extensible Engine.
>
> Having the Engine on Windows is the only way the Engine can interface with
> Active Directory (through Win32 APIs) *and* Novell eDirectory (through NCP
> calls provided by the Novell Client) simultaneously. There's simply no
> viable OES-to-Windows alternative. Likewise, the consumable reporting
> system that NFR 2 uses is *only* available on Windows. Not only did that
> reporting system let us get NFR 2 out in a reasonable timeframe, but it
> also provides a backbone for advanced reporting options and extensible
> reports.
> --
> - NFMS Support Team

Sebastian Cerazy;2248128 wrote:
So all in all (after reading all the post above) is it an overkill, no
matter how good/bad/slow/fat/scalable etc it might be

All I need (for now) is how many avi files exist in folder x, and how many
..mp3 exist in foler y
And how many file not touched in 365 days exist in folder z

This I might get with some Windows based shareware

NFR is coming off my Agreement next time round!

Seb

"Novell File Management Suite Team" <storagemanager_@novell.com> wrote in
message news:512394BA.5010001@novell.com...
> On 2/18/2013 3:26 PM, jffgrnfld wrote:
>
>>
>> How hard would it really have been to recompile the code for a 64-bit
>> OES11 environment of the 1.x version and do some minimal maintenance
>> while at the same time working through these issues of version 2.x?
>>
> jffgrnfld,
>
> Joe's responses to the rest of your concerns have been spot-on, but as
> part of the support and testing team for NFR 2.0, I wanted to address this
> specifically.
>
> The short answer is that it would have been impossible to make the
> existing codebase for NFR 1.x do what we wanted NFR 2.x to do. NFR 1 did
> not use a database to store scan data. It had no concept of, and could
> never have reported on, file system permissions. It was fundamentally
> incapable of reporting on multiple identity systems at once (and the OES
> Engine could never have interfaced with a Windows environment.) Even
> something seemingly simple, like adding email notifications of completed
> activity, would have been a major effort -- as much effort as writing a
> new, enhanced, and extensible Engine.
>
> Having the Engine on Windows is the only way the Engine can interface with
> Active Directory (through Win32 APIs) *and* Novell eDirectory (through NCP
> calls provided by the Novell Client) simultaneously. There's simply no
> viable OES-to-Windows alternative. Likewise, the consumable reporting
> system that NFR 2 uses is *only* available on Windows. Not only did that
> reporting system let us get NFR 2 out in a reasonable timeframe, but it
> also provides a backbone for advanced reporting options and extensible
> reports.
> --
> - NFMS Support Team

So it sounds like for your needs, NFR may be a bit much. That's not Novell's fault.
As for requiring a Windows server, yeah, it may stink, but to be honest, you will be very hard pressed to find any "windows" product that doesn't need a ton of servers, so you may just as well get used to it. (I don't quite care for some of the Windows server requirements myself, but if we dumped OES/Linux and went pure MS, we'd learn to love lots of Windows servers anyway).

You want Sharepoint? Guess what? You'll need at least 3 windows servers, maybe more. Do you use ESRI ArcGIS? Need at least 3 Windows servers, maybe more (it runs on Solaris, sort of but their focus is on Windows). You use Exchange? Lots of Windows servers.

I think there are very few places that are 100% NON-Windows and there are features that are not just in Linux or quite ready yet, for a variety of reasons. We are used to a heterogeneous environment, and NFR supports both platforms, and if we were "pure" Windows, we'd want/need it to run on Windows as well.

--Kevin

Sebastian Cerazy;2248128 wrote:
So all in all (after reading all the post above) is it an overkill, no
matter how good/bad/slow/fat/scalable etc it might be

All I need (for now) is how many avi files exist in folder x, and how many
..mp3 exist in foler y
And how many file not touched in 365 days exist in folder z

This I might get with some Windows based shareware

NFR is coming off my Agreement next time round!

Seb

"Novell File Management Suite Team" <storagemanager_@novell.com> wrote in
message news:512394BA.5010001@novell.com...
> On 2/18/2013 3:26 PM, jffgrnfld wrote:
>
>>
>> How hard would it really have been to recompile the code for a 64-bit
>> OES11 environment of the 1.x version and do some minimal maintenance
>> while at the same time working through these issues of version 2.x?
>>
> jffgrnfld,
>
> Joe's responses to the rest of your concerns have been spot-on, but as
> part of the support and testing team for NFR 2.0, I wanted to address this
> specifically.
>
> The short answer is that it would have been impossible to make the
> existing codebase for NFR 1.x do what we wanted NFR 2.x to do. NFR 1 did
> not use a database to store scan data. It had no concept of, and could
> never have reported on, file system permissions. It was fundamentally
> incapable of reporting on multiple identity systems at once (and the OES
> Engine could never have interfaced with a Windows environment.) Even
> something seemingly simple, like adding email notifications of completed
> activity, would have been a major effort -- as much effort as writing a
> new, enhanced, and extensible Engine.
>
> Having the Engine on Windows is the only way the Engine can interface with
> Active Directory (through Win32 APIs) *and* Novell eDirectory (through NCP
> calls provided by the Novell Client) simultaneously. There's simply no
> viable OES-to-Windows alternative. Likewise, the consumable reporting
> system that NFR 2 uses is *only* available on Windows. Not only did that
> reporting system let us get NFR 2 out in a reasonable timeframe, but it
> also provides a backbone for advanced reporting options and extensible
> reports.
> --
> - NFMS Support Team

So it sounds like for your needs, NFR may be a bit much. That's not Novell's fault.
As for requiring a Windows server, yeah, it may stink, but to be honest, you will be very hard pressed to find any "windows" product that doesn't need a ton of servers, so you may just as well get used to it. (I don't quite care for some of the Windows server requirements myself, but if we dumped OES/Linux and went pure MS, we'd learn to love lots of Windows servers anyway).

You want Sharepoint? Guess what? You'll need at least 3 windows servers, maybe more. Do you use ESRI ArcGIS? Need at least 3 Windows servers, maybe more (it runs on Solaris, sort of but their focus is on Windows). You use Exchange? Lots of Windows servers.

I think there are very few places that are 100% NON-Windows and there are features that are not just in Linux or quite ready yet, for a variety of reasons. We are used to a heterogeneous environment, and NFR supports both platforms, and if we were "pure" Windows, we'd want/need it to run on Windows as well.

--Kevin