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

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

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

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

Don't underestimate the value of things like http://www.google.com/url?sa=t

But that is not the point.

If I go Windows network the I expect to have Windows servers

In pure Novell networking (at least as far as storage is concerned) that is
really silly

Seb

"kjhurni" <kjhurni@no-mx.forums.novell.com> wrote in message
news:kjhurni.5r4ce1@no-mx.forums.novell.com...
>
> 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
>
>
> --
> The opinions expressed are my own.
> Check out my OES2 Guides:
> Installing OES2 SP2:
> http://www.novell.com/communities/node/11600/oes2-sp2-installation-guide
> Upgrading to OES2 with ID Transfer:
> http://www.novell.com/communities/node/11601/oes2-sp2-migration-guide-transfer-id-scenarios
> GroupWise Migration with OES2 ID Transfer:
> http://www.novell.com/communities/node/11602/groupwise-migration-netware-oes2-sp2-transfer-id
> ------------------------------------------------------------------------
> kjhurni's Profile: http://forums.novell.com/member.php?userid=734
> View this thread: http://forums.novell.com/showthread.php?t=464213
>

On 2/27/2013 4:10 AM, Sebastian Cerazy wrote:
> But that is not the point.
>
> If I go Windows network the I expect to have Windows servers
>
> In pure Novell networking (at least as far as storage is concerned) that is
> really silly
>
> Seb

This is only 'silly' if SLES and OES offer a development feature set
comparable to that available on a Windows platform. Unfortunately, it
does not; and that fact, combined with the opportunity for scanning
across identity systems, means a single Windows Engine capable of
scanning eDirectory volumes and Windows shares alike was the obviously
correct model for NFR 2.

--
- NFMS Support Team