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

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