I need a primer on how to Configure Windows 2003 to work with Mac os X panther

[veronica]

I do not have any working knowledge of how to setup Macs in a
networking environment and I have one user who decided to buy a Mac.
Now he wants to print and share files on Windows 2003 domain, HELP!. I
found the following knowledge base article: Q316076 and followed the
steps on how to configure the folders for Mac access, but to no avail.
He cannot connect to the folders using the SMB option or through a web
browser. Also, he cannot configure his system to printer to TCP/IP
printers. Can anyone give me a crash course on how to configure Mac X
panther to work on my Windows 2003 domain? Thanks

 

[William Smith]

I do not have any working knowledge of how to setup Macs in a
networking environment and I have one user who decided to buy a Mac.
Now he wants to print and share files on Windows 2003 domain, HELP!. I
found the following knowledge base article: Q316076 and followed the
steps on how to configure the folders for Mac access, but to no avail.
He cannot connect to the folders using the SMB option or through a web
browser. Also, he cannot configure his system to printer to TCP/IP
printers. Can anyone give me a crash course on how to configure Mac X
panther to work on my Windows 2003 domain? Thanks

Hi Veronica!

I'm listing a few articles from various sources that may help you.

This article gives basic instructions on how a Mac OS X users should
connect to a Windows server.
http://docs.info.apple.com/article.html?artnum=151670

This article gives information for how to disable digital communications
signing on the Windows 2003 server. This is a known issue with the
version of SMB that comes with Mac OS X 10.3. In particular, look for
this snippet:

"SMB Service signing may be disabled in the following node of Default
Domain Controllers policy on the domain controllers organizational unit:

Computer Configuration\Windows Settings\Security Settings\Local
Policies\Security Options\Microsoft Network Server: Digitally sign
communications (always)"
http://support.microsoft.com/default.aspx?scid=kb;en-us;325379

These articles from Apple's site give some information about printing to
Windows printers
http://docs.info.apple.com/article.html?artnum=152259
http://docs.info.apple.com/article.html?artnum=106707

These aren't primers but can give you some insight into what to do. Your
biggest issue will be the "Digitally sign communication (always)"
policy. It's turned on by default on Windows 2003 and must be disabled
so that the SMB client on the Mac can talk to your servers.

I've had better luck using LPR or IP printing instead of printing via
SMB. It's easy to set up but requires that your server have the LPR
printing software installed. This is also known as Print Services for
Unix (found in the Add/Remove Programs Control Panel under the Windows
software button).

One final option you may want to consider is using Dave or ADmitMac from
Thursby http://www.thursby.com/products/. These are third party
commercial products to allow Macs to work in Windows environments. Dave
is geared toward getting a Mac to work in a Windows peer-to-peer network
or server network and ADmitMac is geared toward getting your Mac working
in an Active Directory environment.

Hope this helps! bill

 

[Tony Sheppard]

I have looked everywhere and have found thousands of references to

disabling the digital signing requirement option in the security policy
editor. For 100% of the people, this fixed their problem of the mac not
being ableto connect to the Windows 2003 server... except me. I have
changed that setting and I still cannot get the macs to connect to the
shares on the w2k3 server. I appear to be the only one in the world that it
didn't fix the problem for. I rebooted the server afterwards, 3 times. I
have run gpupdate and checked to verify it is set that way and it is.

When I installed the UAM for the macs (10.2.8 btw) then I could connect to

the shares using the afp:/at/servername. That works but the problem now is,
there appears to be a difference in the filename length allowed using the
different connection types.

I am trying to migrate all mac data from a NT4SP6a server over to our new

server 2003 machine. I can't copy the files because there are thousands of
them that the filename is reporting is too long. I can connect to the NT4
box no problem with SMB and it sees the files just fine and there is no
problem with the length of the filename. But I have to rename the file down
to a maximum of 104 charaters to copy it with the UAM over to the new 2K3
server share. Then it works fine. 105 characters total and it doesn't
work.

The real problem is that the digital signing thing doesn't fix my problem

with the users connecting. Everyone else it fixed it but mine it didn't. I
cannot for the life of me figure that one out.

Please help!!

I know this is not going to be a popular solution, but one way of migrating
the data is to use OS9. We ended up using about 10 iBooks to take up to 6
GB at a time and transfer it to the local drive and then back onto the new
server. This was migrating from a Sun Solaris file server, but the principal
should be the same.

Connect to the mac volume on the old server. Copy chunks of data onto the
local drive. Connect to the mac colume on the new server. Copy the data up.
You don't have OSX's problems with character length.

Failing that have a look at Extreme-Z IP from Group Logic. I haven't looked
at their stuff recently, but they are wizards for solving quirks like this.

HTH

Tony Sheppard

 

[William Smith]

I have looked everywhere and have found thousands of references to disabling
the digital signing requirement option in the security policy editor. For
100% of the people, this fixed their problem of the mac not being ableto
connect to the Windows 2003 server... except me. I have changed that setting
and I still cannot get the macs to connect to the shares on the w2k3 server.
I appear to be the only one in the world that it didn't fix the problem for.
I rebooted the server afterwards, 3 times. I have run gpupdate and checked to
verify it is set that way and it is.When I installed the UAM for the macs
(10.2.8 btw) then I could connect to the shares using the afp:/at/servername.
That works but the problem now is, there appears to be a difference in the
filename length allowed using the different connection types.I am trying to
migrate all mac data from a NT4SP6a server over to our new server 2003
machine. I can't copy the files because there are thousands of them that the
filename is reporting is too long. I can connect to the NT4 box no problem
with SMB and it sees the files just fine and there is no problem with the
length of the filename. But I have to rename the file down to a maximum of
104 charaters to copy it with the UAM over to the new 2K3 server share. Then
it works fine. 105 characters total and it doesn't work.The real problem is
that the digital signing thing doesn't fix my problem with the users
connecting. Everyone else it fixed it but mine it didn't. I cannot for the
life of me figure that one out.Please help!!

The digital signing solution only applies if you're connecting a Mac OS
X station to a Windows server using "smb://..."

Using "afp://..." requires the use of the File Services for Macintosh
being installed on the server.

AFP (Apple Filing Protocol) has not gone beyond version 2.2 on Windows
Server 2003. This is what limits file names to 31 characters.

If you connect via SMB then the 31 character limit is gone but you also
lose the resource fork information that Macs are accustomed to using.
Catch 22.

The UAM is used only if connecting using AFP and is not what's affecting
the file name length.

Although I've never tried this, someone else here has said that copying
from NTFS volume to NTFS volume (between servers) will preserve Mac file
resource forks. I'm doubtful, but again I've never tested this. You
could try copying from NT 4 server to 2003 server directly to see if you
can get your files migrated.

Hope this helps! bill

 

[Rod Dorman]

...
Although I've never tried this, someone else here has said that copying
from NTFS volume to NTFS volume (between servers) will preserve Mac file
resource forks. I'm doubtful, but again I've never tested this. You
could try copying from NT 4 server to 2003 server directly to see if you
can get your files migrated.

I've successfully moved huge directory structures from one spindle to
another on a NT4 platform.

As long as the source, destination, and moving (if it's a third
machine) systems are all aware of NTFS alternate file streams you
shouldn't have any problems.