SFM, SMB and ExtremeZ-IP - boiled down?


B

Bonedoc

I have a Win2k/Nt4.0 network and we have ten Mac users (most of who
use 10.X, 10.2 I believe is average) -

They ALL need to transfer LONG Named ’files’ to a PUBLIC directory on
our
Win2K server(s) - this/these Directories are WINDOW "shares".

With SFM "turned on", there is a 31 character limit on files copied
to this
directory - we TRIAL Tested ExtremeZ-IP after turning off SFM and it
allowed very long file names to be copied with ease!

Now we have a user coming in today, and SFM is off, he logs in on his
Mac
10.2 and "HAS" access to the PUBLIC folder, can copy long named
files and IS NOT listed in the ’user log’ of the trial ExtremeZ-IP
program.

’I’ assume he’s accessing using SMB - is there ANY major reason to buy
a product like ExtremeZ-IP "if" our users can ALL login using the
SMB protocol and transfer long named files (which was the initial
issue)???

Thanks...
 
Ad

Advertisements

J

Jim Seifert [MSFT]

The SMB Apple client keeps getting better and better. There a couple of
issues that impact usability with SMB connections specific to file sharing
from Mac OS X clients to Windows Servers that may or may not be show
stoppers for you: 1.) The creation of .files in addition to the regular
files saved on the share. 2.) Some characters that are legal in Mac OS
file names are not legal on the Windows OS.
 
W

William Smith

Jim Seifert said:
The SMB Apple client keeps getting better and better. There a couple of
issues that impact usability with SMB connections specific to file sharing
from Mac OS X clients to Windows Servers that may or may not be show
stoppers for you: 1.) The creation of .files in addition to the regular
files saved on the share. 2.) Some characters that are legal in Mac OS
file names are not legal on the Windows OS.
And although the environment is all Mac OS X, I thought I'd add that
EZIP or even SFM is favorable to SMB when sharing files with Mac OS 9
clients. Apple's SMB is splitting the resource fork and data fork of
each file (storing one under the file name and the other under the
.._file name) and this makes using the files on Mac OS 9 more difficult.

bill
 
B

Bonedoc

William Smith said:
"Jim Seifert [MSFT]" <jimsei@online.microsoft.com>
wrote:
The SMB Apple client keeps getting better and better. There a couple of
issues that impact usability with SMB connections specific to file sharing
from Mac OS X clients to Windows Servers that may or may not be show
stoppers for you: 1.) The creation of .files in addition to the regular
files saved on the share. 2.) Some characters that are legal in Mac OS
file names are not legal on the Windows OS.
And although the environment is all Mac OS X, I thought I'd
add that
EZIP or even SFM is favorable to SMB when sharing files with
Mac OS 9
clients. Apple's SMB is splitting the resource fork and data
fork of
each file (storing one under the file name and the other under
the
.._file name) and this makes using the files on Mac OS 9 more
difficult.

bill
Thanks Jim, William...
We do have a lot of ’creatively’ named files that have been an issue
in the past. Seems that SMB does ’not’ support those (and that may’ve
been GOOD
before they were created) and so we need the function of ’weird’ file
name support (/$#*\ and etc) from ExtremeZ-IP. In addition, and I’m
still checking, the PASSWORD support thru our NT based (soon to be all
Win2003Server) is only eight letters... I’m checking to see if the
ExtremeZ-IP supports the full 14 that NT currently allows.

Many thanks... any other thoughts on this greatly appreciated.
 
W

William Smith

Bonedoc said:
Thanks Jim, William...
We do have a lot of ’creatively’ named files that have been an issue
in the past. Seems that SMB does ’not’ support those (and that may’ve
been GOOD
before they were created) and so we need the function of ’weird’ file
name support (/$#*\ and etc) from ExtremeZ-IP. In addition, and I’m
still checking, the PASSWORD support thru our NT based (soon to be all
Win2003Server) is only eight letters... I’m checking to see if the
ExtremeZ-IP supports the full 14 that NT currently allows.

Many thanks... any other thoughts on this greatly appreciated.

To allow your Macs to use long passwords when connecting to Windows
servers, install the Microsoft UAM found here on Microsoft's site
<http://www.microsoft.com/mac/otherproducts/otherproducts.aspx?pid=window
s2000sfm>.

I believe it allows up to 14 characters for Windows NT passwords and up
to 64 characters for Windows 2000 and higher servers.

This works for SFM but maybe not for EZIP. I've never tried. I'd bet
EZIP may have its own mechanisms for handling long passwords if it can't
use the UAM.

Hope this helps! bill
 
B

Bonedoc

William Smith said:
appreciated.


To allow your Macs to use long passwords when connecting to
Windows
servers, install the Microsoft UAM found here on Microsoft's
site
<http://www.microsoft.com/mac/otherproducts/otherproducts.aspx?pid=window
s2000sfm>.

I believe it allows up to 14 characters for Windows NT
passwords and up
to 64 characters for Windows 2000 and higher servers.

This works for SFM but maybe not for EZIP. I've never tried.
I'd bet
EZIP may have its own mechanisms for handling long passwords
if it can't
use the UAM.

Hope this helps! bill
Thanks William... good to know and I’ll go download it.
Yes, I "think" ExtremeZ-IP may have its own devices for long files
names but they have not answered that question yet. I intend to test
it today.

The issue may be mute. I misread the price for ten users (we have 8 or
9 users in a 50 user office) and see the corrected cost would be near
the price of a Mac Server... so we are weighing those two options. The
Server would work well with our users, I’m TRYING to determine how it
would interface with our NT/Win2K Network (soon to be just Win2K/2003
Srvrs) so not sure
which way to jump...

Thanks for any input...

Doc
 
Ad

Advertisements

W

William Smith

Bonedoc said:
Thanks William... good to know and I’ll go download it.
Yes, I "think" ExtremeZ-IP may have its own devices for long files
names but they have not answered that question yet. I intend to test
it today.

The issue may be mute. I misread the price for ten users (we have 8 or
9 users in a 50 user office) and see the corrected cost would be near
the price of a Mac Server... so we are weighing those two options. The
Server would work well with our users, I’m TRYING to determine how it
would interface with our NT/Win2K Network (soon to be just Win2K/2003
Srvrs) so not sure
which way to jump...

Thanks for any input...

Hi Doc!

For only 10 users the price of EZIP should be nowhere near the price of
a Mac server.
<http://www.grouplogic.com/products/extreme/pricingProd.cfm> Keep in
mind that you don't have to buy EZIP print services.

When deciding whether to buy a server or not, determine where your
support will come from. If you have no server experience then go with a
platform that's supported in your company. Bringing in your own server
can feel liberating, especially if you feel your current server
administrators are difficult to deal with, but when something goes wrong
you're stuck as your own support. Mac OS X Server troubleshooting can be
a nightmare for the unexperienced.

If your server administrators refuse to support the EZIP application
then you may have no choice but to install a Mac server.

As for interfacing two different servers, you'd "bind" the Mac OS X
server to Active Directory on Windows. But this will happen only with a
Windows administrator's permission. This would allow your server to use
the users and groups from the Windows network, which means one user ID
and password instead of two or more.

Good luck! bill
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

SFM Problem 5
Problem Installing SFM 0
Win2000 SFM and backups 6
SFM Won't Start 1
SFM 5 secs delay 6
SFM on Win2k Requirements - Recommendations 0
Moving away from SFM... 1
SFM 5 seconds delay 0

Top