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

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

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