Previously known as ExtremeZ-IP, Acronis Files Connect crosses the line between Windows and MAC OS systems, allowing users of the latter OS type to conveniently access resources located on a Windows computer. To put it another way, Acronis Files Connect bypasses incompatibility issues that might occur due to the use of the Windows' native file SMB file sharing protocol on MAC when accessing. With ExtremeZ-IP you get seamless integration with your existing Windows. Has anyone managed to get hold of a serial for version 8?
AppleTalkDeveloper(s)Apple Inc.Introduced1985; 34 years ago ( 1985)Hardware, othersAppleTalk is a discontinued developed by for their. AppleTalk includes a number of features that allow to be connected with no prior setup or the need for a centralized router or server of any sort. Connected AppleTalk-equipped systems automatically assign addresses, update the distributed namespace, and configure any required inter-networking routing.AppleTalk was released in 1985, and was the primary protocol used by Apple devices through the 1980s and 1990s. Versions were also released for the and compatibles and the. AppleTalk support was also available in most networked printers (especially ), some, and a number of.The rise of during the 1990s led to a reimplementation of most of these types of support on that protocol, and AppleTalk became unsupported as of the release of in 2009. Many of AppleTalk's more advanced autoconfiguration features have since been introduced in, while serves similar needs.
Contents.History AppleNet After the release of the computer in January 1983, Apple invested considerable effort in the development of a (LAN) system for the machines. Known as AppleNet, it was based on the seminal but running on a custom 1 Mbit/s system rather than Xerox's 2.94 Mbit/s.
AppleNet was announced early in 1983 with a fall introduction at the target price of $500 for plug-in AppleNet cards for the Lisa and the.At that time, early LAN systems were just coming to market, including,. This was a topic of major commercial effort at the time, dominating shows like the (NCC) in Anaheim in May 1983. All of the systems were jockeying for position in the market, but even at this time Ethernet's widespread acceptance suggested it was to become a de facto standard. It was at this show that asked Gursharan Sidhu a seemingly innocuous question, 'Why has networking not caught on?'
Four months later, in October, AppleNet was cancelled. At the time, they announced that 'Apple realized that it's not in the business to create a networking system. We built and used AppleNet in-house, but we realized that if we had shipped it, we would have seen new standards coming up.'
In January, Jobs announced that they would instead be supporting 's Token Ring, which he expected to come out in a 'few months'. AppleBus Through this period, Apple was deep in development of the Macintosh computer. During development, engineers had made the decision to use the serial controller chip (SCC) instead of the lower-cost and more common to provide connections.
The SCC cost about $5 more than a UART, but offered much higher speeds of up to 250 kilobits per second (or higher with additional hardware) and internally supported a number of basic networking-like protocols like IBM's.The SCC was chosen because it would allow multiple devices to be attached to the port. Equipped with similar SCCs could communicate using the built-in protocols, interleaving their data with other peripherals on the same bus. This would eliminate the need for more ports on the back of the machine, and allowed for the elimination of for supporting more complex devices.
The initial concept was known as AppleBus, envisioning a system controlled by the host Macintosh polling 'dumb' devices in a fashion similar to the modern. AppleBus networking The Macintosh team had already begun work on what would become the, and had considered a number of other options to answer the question of how to share these expensive machines and other resources. A series of memos from Bob Belleville clarified these concepts, outlining the Mac, LaserWriter and a system which would become the. By late 1983 it was clear that IBM's Token Ring would not be ready in time for the launch of the Mac, and might miss the launch of these other products as well. In the end, Token Ring would not ship until October 1985.Jobs' earlier question to Sidhu had already sparked a number of ideas. When AppleNet was cancelled in October, Sidhu led an effort to develop a new networking system based on the AppleBus hardware.
This new system would not have to conform to any existing preconceptions, and was designed to be worthy of the Mac – a system that was user-installable, had zero-configuration, and no fixed network addresses – in short, a true plug-and-play network. Considerable effort was needed, but by the time the Mac was released, the basic concepts had been outlined, and some of the low-level protocols were on their way to completion. Sidhu mentioned the work to Belleville only two hours after the Mac was announced.The 'new' AppleBus was announced in early 1984, allowing direct connection from the Mac or Lisa through a small box that plugged into the serial port and connected via cables to the next computer upstream and downstream. Adaptors for and were also announced. Apple also announced that AppleBus networks could be attached to, and would appear to be a single node within, a Token Ring system. Details of how this would work were sketchy. AppleTalk Just prior to its release in early 1985, AppleBus was renamed AppleTalk.
The system had a number of limitations, including a speed of only 230.4 kbit/s, a maximum distance of 1000 feet from end to end, and only 32 nodes per LAN. But as the basic hardware was built into the Mac, adding nodes only cost about $50 for the adaptor box. In comparison, Ethernet or Token Ring cards cost hundreds or thousands of dollars. Additionally, the entire required only about 6 kB of RAM, allowing it to run on any Mac.The relatively slow speed of AppleTalk allowed further reductions in cost. Instead of using 's balanced transmit and receive circuits, the AppleTalk Personal Network cabling used a single common, which limited speeds to about 500 kbit/s, but allowed one conductor to be removed. This meant that common three-conductor cables could be used for wiring.
Additionally, the adaptors were designed to be 'self-terminating', meaning that nodes at the end of the network could simply leave their last connector unconnected. There was no need for the wires to be connected back together into a loop, nor the need for hubs or other devices.The system was designed for future expansion; the addressing system allowed for expansion to 255 nodes in a LAN (although only 32 could be used at that time), and by using 'bridges' (which came to be known as 'routers', although technically not the same) one could interconnect LANs into larger collections. 'Zones' allowed devices to be addressed within a bridge-connected internet. Additionally, AppleTalk was designed from the start to allow use with any potential underlying physical link.The main advantage of AppleTalk was that it was completely maintenance-free. To join a device to a network, you simply plugged the adaptor into the machine, then connected a cable from it to any free port on any other adaptor. AppleTalk's internal protocols negotiated a working network address number, automatically gave the computer a human-readable name, and collected up a list of the names and types of other machines on the network so the user could browse the devices through the GUI-based.
AppleTalk was so easy to use that ad-hoc networks tended to appear whenever multiple Macs were in the same room. Apple would later use this in an advertisement showing a network being created between two seats in an airplane. PhoneNet and other adaptors A thriving 3rd party market for AppleTalk devices developed over the next few years.
One particularly notable example was an alternate adaptor designed by and commercialized by Farallon as in 1987. This was essentially a replacement for Apple's connector that had conventional instead of Apple's round connectors.
PhoneNet allowed AppleTalk networks to be connected together using normal telephone wires, and with very little extra work, could run analog phones and AppleTalk on a single four-conductor phone cable.Other companies took advantage of the SCC's ability to read external clocks in order to support higher transmission speeds, up to 1 Mbit/s. In these systems the external adaptor also included its own, and used that to signal the SCC's clock input pins.
The best known such system was Centram's FlashTalk, which ran at 768 kbit/s, and was intended to be used with their networking system. A similar solution was the 850 kbit/s DaynaTalk, which used a separate box that plugged in between the computer and a normal LocalTalk/PhoneNet box.
Dayna also offered a PC expansion card that ran up to 1.7 Mbit/s when talking to other Dayna PC cards. Several other systems also existed with even higher performance, but these often required special cabling that was incompatible with LocalTalk/PhoneNet, and also required patches to the networking stack that often caused problems.EtherTalk, TokenTalk and AppleShare By 1987 Ethernet was clearly winning the standards battle over Token Ring, and in the middle of that year Apple introduced EtherTalk 1.0 for the newly released computer. The package included both a card with Ethernet ports and a new Network that allowed the user to select which physical connection to use for networking (from 'Built-in' or 'EtherTalk'). The release's new networking stack also expanded the system to allow a full 255 nodes per LAN. With its release, AppleTalk Personal Network was renamed.
Token Ring would eventually be supported with the similar TokenTalk product, which used the same Network control panel and underlying software. Many third party companies would introduce compatible Ethernet and Token Ring cards that used these same drivers.The appearance of EtherTalk also led to a problem: Networks with new and old Macs needed some way to communicate between each other.
This could be as simple as a network of Ethernet Mac IIs trying to talk to a LaserWriter. Apple had considered the problem, and AppleTalk included the possibility for a low-cost, but they felt it would be a low-volume product and left it to third parties.
A number of companies responded, both existing communications vendors like and, as well as newly formed companies like Kinetics. Contrary to Apple's belief these would be low-volume, by the end of 1987, 130,000 such systems were in use. AppleTalk was at that time the most used networking system in the world, with over three times the installations of any other vendor. 1987 also marked the introduction of the product, a dedicated that ran on any Mac with 512 kB of or more. A common AppleShare machine was the with an external. AppleShare was the #3 in the late 1980s, behind and Microsoft's. AppleShare was effectively the replacement for the failed Macintosh Office efforts, which had been based on a dedicated file server device.AppleTalk Phase II and other developments A significant re-design was released in 1989 as AppleTalk Phase II.
In many ways, Phase II can be considered an effort to make the earlier version (never called Phase I) more generic. LANs could now support more than 255 nodes, and zones were no longer associated with physical networks, but were entirely virtual constructs used simply to organize nodes. For instance, one could now make a 'Printers' zone that would list all the printers in an organization, or one might want to place that same device in the '2nd Floor' zone to indicate its physical location. Phase II also included changes to the underlying inter-networking protocols to make them less 'chatty', which had previously been a serious problem on networks that bridged over wide-area networks.By this point Apple had a wide variety of communications products under development, and many of these were announced along with AppleTalk Phase II. These included updates to EtherTalk and TokenTalk, AppleTalk software and LocalTalk hardware for the, EtherTalk for Apple's allowing it to use LaserPrinters and other network resources, and the Mac X.25 and products.Ethernet had become almost universal by 1990, and it was time to build Ethernet into Macs direct from the factory. However, the physical wiring used by these networks was not yet completely standardized. Apple solved this problem using a single port on the back of the computer into which the user could plug an adaptor for any given cabling system.
This FriendlyNet system was based on the industry-standard or AUI, but deliberately chose a non-standard connector that was smaller and easier to use, which they called 'Apple AUI', or AAUI. FriendlyNet was first introduced on the and computers, and used across much of the Mac line for some time.
As with LocalTalk, a number of 3rd party FriendlyNet adaptors quickly appeared.As became the de facto cabling system for Ethernet, second-generation machines added a 10BASE-T port in addition to AAUI. The and lower-end Power Macs also added 10BASE-T.
The // were the final Macs to include AAUI, and 10BASE-T became universal starting with the and.The capital-I Internet In 1988 Apple had released, a system that allowed the Mac to support on machines with suitable Ethernet hardware. However, this left many universities with the problem of supporting IP on their many LocalTalk-equipped Macs. Pioneered development of, which allowed IP packets to be routed over LocalTalk networks with the support of a suitable 'gateway' machine. These were initially custom devices, but it was soon common to include MacIP support in LocalTalk-to-Ethernet bridges.
MacTCP would not become a standard part of the until 1994, by which time it also supported and.For some time in the early 1990s, the Mac was a primary client on the rapidly expanding Internet. Among the better known programs in wide use were Fetch, Eudora, eXodus, NewsWatcher and the NCSA packages, especially and its offspring,.
Additionally, a number of server products appeared that allowed the Mac to host Internet content. Through this period, Macs had about 2 to 3 times as many clients connected to the Internet as any other platformdespite the relatively small overall marketshare.As the world quickly moved to IP for both LAN and WAN uses, Apple was faced with maintaining two increasingly outdated code bases on an ever-wider group of machines as well as the introduction of the based machines. This led to the efforts, which re-implemented both MacTCP and AppleTalk on an entirely new code base adapted from the Unix standard.
Early versions had problems and did not become stable for some time. By that point, Apple was deep in their ultimately doomed efforts.Legacy and abandonment With the purchase of and subsequent development of, AppleTalk was strictly a legacy system. Support was added to OS X in order to provide support for the large number of existing AppleTalk devices, notably and file shares, but alternate connection solutions common in this era, notably USB for printers, limited their demand. As Apple abandoned many of these product categories, and all new systems were based on IP, AppleTalk became less and less common. AppleTalk support was finally removed from the MacOS in in 2009.However, the loss of AppleTalk did not reduce the desire for networking solutions that combined its ease-of-use with IP routing. Apple has led development of many such efforts, from the introduction of the router to the development of the system and their implementation of it,.Design. This section needs additional citations for.
Unsourced material may be challenged and removed.Find sources: – ( October 2007) The AppleTalk design rigorously followed the of protocol layering. Unlike most of the early systems, AppleTalk was not built using the archetypal system.
The intended target was not Ethernet, and it did not have 48-bit addresses to route. Nevertheless, many portions of the AppleTalk system have direct analogs in XNS.One key differentiation for AppleTalk was it contained two protocols aimed at making the system completely self-configuring. The AppleTalk address resolution protocol ( AARP) allowed AppleTalk hosts to automatically generate their own network addresses, and the Name Binding Protocol ( NBP) was a dynamic system for mapping network addresses to user-readable names. Although systems similar to AARP existed in other systems, for instance, nothing like NBP has existed until recently.Both AARP and NBP had defined ways to allow 'controller' devices to override the default mechanisms.
The concept was to allow routers to provide the information or 'hardwire' the system to known addresses and names. On larger networks where AARP could cause problems as new nodes searched for free addresses, the addition of a router could reduce 'chattiness.' Together AARP and NBP made AppleTalk an easy-to-use networking system. New machines were added to the network by plugging them and optionally giving them a name. The NBP lists were examined and displayed by a program known as the which would display a list of machines on the local network, divided into classes such as file-servers and printers.Addressing An AppleTalk address was a four-byte quantity. This consisted of a two-byte network number, a one-byte node number, and a one-byte socket number.
Of these, only the network number required any configuration, being obtained from a router. Each node dynamically chose its own node number, according to a protocol (originally the LocalTalk Link Access Protocol LLAP and later the AppleTalk Address Resolution Protocol, AARP) which handled contention between different nodes accidentally choosing the same number.
For socket numbers, a few well-known numbers were reserved for special purposes specific to the AppleTalk protocol itself. Apart from these, all application-level protocols were expected to use dynamically-assigned socket numbers at both the client and server end.Because of this dynamism, users could not be expected to access services by specifying their address. Instead, all services had names which, being chosen by humans, could be expected to be meaningful to users, and also could be sufficiently long to minimize the chance of conflicts.As NBP names translated to an address, which included a socket number as well as a node number, a name in AppleTalk mapped directly to a service being provided by a machine, which was entirely separate from the name of the machine itself. Thus, services could be moved to a different machine and, so long as they kept the same service name, there was no need for users to do anything different in order to continue accessing the service. And the same machine could host any number of instances of services of the same type, without any network connection conflicts.Contrast this with A records in the, in which a name translates to a machine's address, not including the port number that might be providing a service.
Thus, if people are accustomed to using a particular machine name to access a particular service, their access will break when the service is moved to a different machine. This can be mitigated somewhat by insistence on using CNAME records indicating service rather than actual machine names to refer to the service, but there is no way of guaranteeing that users will follow such a convention. Some newer protocols, such as and use DNS to identify services by name, which is much closer to the AppleTalk model.
Protocols. This section does not any. Unsourced material may be challenged.
( June 2012) AppleTalk Address Resolution Protocol AARP resolves AppleTalk addresses to, usually, addresses. It is functionally equivalent to.AARP is a fairly simple system. When powered on, an AppleTalk machine broadcasts an AARP probe packet asking for a network address, intending to hear back from controllers such as routers.
If no address is provided, one is picked at random from the 'base subnet', 0. It then broadcasts another packet saying 'I am selecting this address', and then waits to see if anyone else on the network complains. If another machine has that address, it will pick another address, and keep trying until it finds a free one. On a network with many machines it may take several tries before a free address is found, so for performance purposes the successful address is 'written down' in and used as the default address in the future. This means that in most real-world setups where machines are added a few at a time, only one or two tries are needed before the address effectively become constant.AppleTalk Data Stream Protocol This was a comparatively late addition to the AppleTalk protocol suite, done when it became clear that a -style reliable connection-oriented transport was needed.
Significant differences from TCP were that:. a connection attempt could be rejected. there were no 'half-open' connections; once one end initiated a tear-down of the connection, the whole connection would be closed ( i.e., ADSP is, not ). AppleTalk had an included attention message system which allowed short messages to be sent which would bypass the normal stream data flow. These were delivered reliably but out of order with respect the to stream.
Any attention message would be delivered as soon as possible instead of waiting for the current stream byte sequence point to become current.Apple Filing Protocol The (AFP), formerly AppleTalk Filing Protocol, is the protocol for communicating with file servers. Built on top of AppleTalk Session Protocol (for legacy AFP over DDP) or the (for AFP over TCP), it provides services for authenticating users (extensible to different authentication methods including two-way random-number exchange) and for performing operations specific to the Macintosh filesystem. AFP is still in use in macOS, even though most other AppleTalk protocols have been deprecated.AppleTalk Session Protocol ASP was an intermediate protocol, built on top of ATP, which in turn was the foundation of AFP. It provided basic services for requesting responses to arbitrary commands d performing out-of-band status queries. It also allowed the server to send asynchronous attention messages to the client.Datagram Delivery Protocol DDP was the lowest-level data-link-independent transport protocol.
It provided a service with no guarantees of delivery. All application-level protocols, including the infrastructure protocols NBP, RTMP and ZIP, were built on top of DDP. AppleTalk's DDP corresponds closely to the Network layer of the Open Systems Interconnection communication model.Name Binding Protocol Name Binding Protocol was a dynamic, distributed system for managing AppleTalk names. When a service started up on a machine, it registered a name for itself as chosen by a human administrator. At this point, NBP provided a system for checking that no other machine had already registered the same name.
Later, when a client wanted to access that service, it used NBP to query machines to find that service. NBP provided browseability ('what are the names of all the services available?' ) as well as the ability to find a service with a particular name.
Names were human readable, containing spaces, upper and lower case letters, and including support for searching.AppleTalk Echo Protocol AEP (AppleTalk Echo Protocol) is a transport layer protocol designed to test the reachability of network nodes. AEP generates packets to be sent to the network node and is identified in the Type field of a packet as an AEP packet. The packet is first passed to the source DDP. After it is identified as an AEP packet, it is forwarded to the node where the packet is examined by the DDP at the destination. After the packet is identified as an AEP packet, the packet is then copied and a field in the packet is altered to create an AEP reply packet, and is then returned to the source node.Printer Access Protocol PAP was the standard way of communicating with printers. It was built on top of ATP. When a PAP connection was opened, each end sent the other an ATP request which basically meant 'send me more data'.
The client's response to the server was to send a block of PostScript code, while the server could respond with any diagnostic messages that might be generated as a result, after which another 'send-more-data' request was sent. This use of ATP provided automatic; each end could only send data to the other end if there was an outstanding ATP request to respond to.PAP also provided for out-of-band status queries, handled by separate ATP transactions. Even while it was busy servicing a print job from one client, a PAP server could continue to respond to status requests from any number of other clients. This allowed other Macintoshes on the LAN that were waiting to print to display status messages indicating that the printer was busy, and what the job was that it was busy with.Routing Table Maintenance Protocol RTMP was the protocol by which routers kept each other informed about the topology of the network. This was the only part of AppleTalk that required periodic unsolicited broadcasts: every 10 seconds, each router had to send out a list of all the network numbers it knew about and how far away it thought they were.Zone Information Protocol ZIP was the protocol by which AppleTalk network numbers were associated with zone names.
A zone was a subdivision of the network that made sense to humans (for example, 'Accounting Department'); but while a network number had to be assigned to a topologically-contiguous section of the network, a zone could include several different discontiguous portions of the network.Physical implementation. Farallon PhoneNET adapterThe initial default hardware implementation for AppleTalk was a high-speed serial protocol known as that used the 's built-in ports at 230.4 kbit/s. LocalTalk used a splitter box in the RS-422 port to provide an upstream and downstream cable from a single port. The topology was a: cables were daisy-chained from each connected machine to the next, up to the maximum of 32 permitted on any segment. The system was slow by today's standards, but at the time the additional cost and complexity of networking on PC machines was such that it was common that Macs were the only networked personal computers in an office. Other larger computers, such as UNIX or VAX workstations, would commonly be networked via Ethernet.Other physical implementations were also available.
A very popular replacement for LocalTalk was, a 3rd party solution from Farallon Computing, Inc. (renamed, acquired by in 2007) that also used the RS-422 port and was indistinguishable from LocalTalk as far as Apple's LocalTalk port drivers were concerned, but ran over the two unused wires in standard four-wire phone cabling. Foreshadowing today's network hubs and switches, Farallon provided solutions for PhoneNet to be used in 'star' as well as bus configurations, with both 'passive' star connections (with the phone wires simply bridged to each other at a central point), and 'active' star with 'PhoneNet Star Controller' hub hardware. Apple's LocalTalk connectors didn't have a locking feature, so connectors could easily come loose, and the bus configuration resulted in any loose connector bringing down the whole network, and being hard to track down. PhoneNet RJ-11 connectors, on the other hand, snapped into place, and in a star configuration any wiring issue only affected one device, and problems were easy to pinpoint. PhoneNet's low cost, flexibility, and easy troubleshooting resulted in it being the dominant choice for Mac networks into the early 1990s.AppleTalk protocols also came to run over Ethernet (first coaxial and then twisted pair) and physical layers, labeled by Apple as EtherTalk and TokenTalk, respectively. EtherTalk gradually became the dominant implementation method for AppleTalk as Ethernet became generally popular in the PC industry throughout the 1990s.
Besides AppleTalk and, any Ethernet network could also simultaneously carry other protocols such as and.Networking model OSI ModelCorresponding AppleTalk layers(AFP)(AFP)Zone Information Protocol AppleTalk Session Protocol (ASP)AppleTalk Data Stream Protocol (ADSP)AppleTalk Transaction Protocol (ATP)(AEP)Name Binding Protocol Routing Table Maintenance Protocol (RTMP)Datagram Delivery Protocol EtherTalk Link Access Protocol (ELAP)LocalTalk Link Access Protocol (LLAP)TokenTalk Link Access Protocol (TLAP)Fiber Distributed Data Interface driverEthernet driverdriverdriverVersions. This section needs expansion. You can help. ( June 2008)AppleTalk versionCorresponds toNotes56System 7.057.0.4System 7.1258.1.1System 7.1.258.1.3System 7.560.3Mac OS 7.6.1Open Transport 1.360.0a6Mac OS 8.6Open Transport 2.0.33.0Mac OS X 10.0.32.1, 2.0 and even 1.12.2, 3.0 and 3.13.2Cross-platform solutions When AppleTalk was first introduced, the dominant office computing platform was the PC compatible running MS-DOS. Apple introduced the AppleTalk PC Card in early 1987, allowing PCs to join AppleTalk networks and print to LaserWriter printers. A year later AppleShare PC was released, allowing PCs to access AppleShare file servers.The 'TOPS Teleconnector' MS-DOS networking system over AppleTalk system enabled MS-DOS PCs to communicate over AppleTalk network hardware; it comprised an AppleTalk interface card for the PC and a suite of networking software allowing such functions as file, drive and printer sharing. As well as allowing the construction of a PC-only AppleTalk network, it allowed communication between PCs and Macs with TOPS software installed.
John Markoff, InfoWorld, 14 February 1983, p. 14., Slide 3. David Ahl, Creative Computing, August 1983, p.
188. ^, p. xxiii. ^, p. 45., Slide 6., Zilog, p. 1-1., Slide 9. 22 April 2012 at the, Section 1.2., Slide 10. Jim Barimo, InfoWorld, 26 March 1984, pp 45-46., Slide 15., Slide 19., Slide 17.
Lee Larson, Louisville Computer News, October 1999., Slide 28. Tim Brown, Network World, 26 October 1987, p. 27.
John Battelle, MacWEEK, 23 May 1989., InfoWorld, 11 December 1989., Slide 30., Slide 31., Slide 32. Laura DiDio, Network World, 11 July 1988, p. 17., Slide 34. ^, Slide 36., Slide 43. Calore, Michael. Retrieved 14 October 2017., Slide 46., Slide 51., Slide 54.
Retrieved on 2 September 2009., p. 12-19. Mary Petrosky, Network World, 2 February 1987, p. 4., InfoWorld, 18 January 1988, p.
29. Mark Stephens, InfoWorld, 25 January 1988, p. 12Bibliography.
Hi guysI'm starting a new job in the next few weeks going to a nice small media agency that are doubling in size and want to have an IT infrastructure.Front end is all Mac right now(this could change) back end is whatever I want to put in. They have a consultant at the moment who's made some recommendations. Virtualised environment using VMware Essentials running 3 hosts, a single AD controller, 1 backup server and 1 file server, hosted Exchange. All the guests running server 2008.Firstly there will be a second AD controller, non-virtualised.Second he has recommended ExtremeZ-IP and I can never see the point of it. I've worked plenty of offices with Mac's and Windows file servers and not had a problem with file access.Does anyone have any advice on if it is really needed?Like I said I've never had problems with Mac's on SMB.
Ip Serial Port
I would use Linux and Netatalk but I'm not too keen on trying to enforce Windows ACLs on a Linux box with Mac's accessing them.Thanks. SMB is no longer fully supported? That's quite the news flash:.NO. file-sharing for Windows clients!
LOL.SMB = CIFS vs 'Samba' and Mac OS X doesn't even use that for the client protocol (no, it does not. Not file-serving to Win clients, the Mac client connection to Samba or CIFS is not Samba, not in any recent Mac OS X).ExtremeZ-IP is highly regarded but I haven't used it.The smb client in OS X is good.If you're going to use network homes, then yes, I'd say go with ExtremeZ-IP and dedicated AFP shares for that purpose.Hands down, AFP is best for hosting Mac network homes. OK wouldn't be using DFS or separating things out on VLANs, OS X Lion and above seem ok natively to Windows printers, though if I need a print server I would probably use a Mac mini and load on the old version of OS X Server they have. I much prefer the old print server over Apple CUPS implementation.I really only see ExtremeZ-IP and an implementation of AFP for Windows. OK it may do more but it seems to duplicate existing functions on a Mac and I can never see the value in the product for features which may be 'nice' but not essential.
I use and rely on ExtremeZ-IP in my environment. Every one of my 50+ users connects to a central fileserver that runs ExtremeZ-IP.We use it in-house because users are so reliant on spotlight searching.
ExtremeZ-IP allows for its own crawling of files that creates an index that users can search from, or it can leverage Windows Search and translate those results to Spotlight search results.Another nice feature with ExtremeZ-IP is the ability to prevent unauthorized characters from being used in the filename. If your Mac users like using things like backslashes in filenames, ExtremeZ-IP can either give the user an error saying to use something else, or it can accept illegal characters and will give a placeholder character in Windows. It also prevents my users from renaming a file to just be a space.My users LOVE using quick look so they hit space bar all the time over documents. Oftentimes they'll click a document, Finder will toggle to rename the file, and they'll hit Space and then rename the document something like '.pdf'. ExtremeZ-IP prevents this from happening now, and it's been a really good side-effect of using the product.It has worked great for us as we moved to a Server 2k8 backend vs an old Xserve that was acting as a fileserver.If your users are fine with using SMB shares (or something else like NFS, etc) then ExtremeZ-IP might not be worth the cost.
If they want functional spotlight searches over network shares, it's the only solution I've come across that works. Browsing through shares and quicklook/opening documents is the same as it was on our old Xserve.Searching is a bit different. When I enable spotlight searching, doing searches can be a bit unresponsive the more I type.
I guess this is since every letter I type queries a new spotlight search, so when I type someone's name in like 'SmithJohn', it's searching for S, then Sm, then Smi, etc.It doesn't freeze or screw up Finder or anything, but it is a bit less fluid than a Mac sharing through native AFP. My users have grown accustomed to it, though.My fileserver running ExtremeZ-IP is a Dell R520 running SAS drives in a RAID 6 on Windows Server 2008 Standard.
It just has the fileserver role enabled on it.ExtremeZ-IP has the feature to migrate all existing SMB shares, so it makes it pretty easy to convert existing shares to AFP. AFP was supported on and got ditched in Server 2008!My recollection was that file server for Macintosh was an AppleTalk implementation, not an AFP implementation. Mac OS Lion and Mountain Lion have support for resolving DFS namespaces as long as you're not putting network homes into DFS.
AppleTalk is one of those technologies that is best dealt with by placing it into a burlap sack and beating with a stick until it stops whimpering, and then toss the sack and it's contents into the incinerator. In any case, the File Server for Macintosh was something that should have been removed from Windows long before Server 2008.As others have noted, the big advantage ExtremeZ-IP brings to the table is network spotlight searching and other Mac features such as Network Time Machine that only work over AFP. It's also nice to be able to throw back the error at Mac users when they try and use a file name that Windows doesn't like when you're working in a mixed Windows and Mac environment.In a previous job I deployed ExtremeZ-IP specifically to use the Network Spotlight for searching through our job archive.
It didn't always work well as files and folders wouldn't show up until the Windows Search Indexer indexed the files, and we ran into the limit of files that the Windows Search Indexer will index. After some fine tuning on the Windows Search side of things (only file/folder names, only limiting file types, increasing file limit, and adding some more memory and CPUs to the windows server to let the overworked search indexer do it's job) we got it tuned fairly well.
Akp982 wrote:Eric shout if you have any questions. Might be able to help. Make sure you setup windows search to enable afp spotlight search.I do have one question. I'm trying to setup Home directories but its not very clear what part of the user profile it pulls.I've tried Profile Path and Home Directory both without success. In fact when I put in the home directory in AD pointing to a valid shared folder, and I setup ExtremeZ-IP to share that folder it takes forever to login with the domain account and I get no local folders, just a question mark.So I assume I'm on the right path. If I login with another domain account without a home profile option it works, the folders are just on the local Mac.I'm pretty pleased with the software so far.
I see crazy read/write speeds compared to SMB. I even took the extra step of joining the Mac to the domain which worked in one of the rare occasions. Hi,I have been using ExtremeZ-IP for a few years and would recommend it whole heartedly.Firstly, the performance is noticeably better in terms of using finder, thumbnails etc and file copies. If I get time I will get some performance comparisons for file copies.But the main thing, is for the IT admins to limit what characters, file and folder lengths etc that can be used. Try this testOn a Mac create a folder with, or space at the beginning of the name of the folder or make it the whole path greater than 260 characters. Now go to a PC and try to rename that folder or move it or do much at all. Once you have to a 10TB Windows File Server migration with these kind of characters, you will feel the pain.
Robocopy is the only way for this kind of thing. Another thing is backups. As most backups run on Windows Systems in these environments, they may very well have issues restoring a file to that has illegal windows characters or path length. They now also support DFS, but has limited use, as the Extreme-IP server then become the single point of failure and you have to install a client on every mac to make it work properly.My 2 cents.CheersTOny.