activEcho
Client: Windows 8 is supported by activEcho client 2.7 or later.
Server: Windows 8 is not supported.

ArchiveConnect
AFP-based Servers: ExtremeZ-IP 8.0.3 or later is supported on Windows 8 for use with ArchiveConnect (see below).
SMB-based Servers: Windows 8 has not yet been certified for compatibility with ArchiveConnect

ExtremeZ-IP
Server: Windows 8 is supported by ExtremeZ-IP 8.0.3 or later.

MassTransit
Server: Windows 8 is not supported.
Windows Web Client: Windows 8 is supported when using the MassTransit 7.2.7 or later web client.

mobilEcho
Server: Windows 8 is supported by mobilEcho 4.3 or later.

Microsoft has identified an NTFS corruption issue that can cause a Windows 2008 server and Windows 7 to freeze or hang. The specific corruption that causes the problem is a multi-level circular NTFS reference that Windows self-healing cannot fix. The OS hang caused by the corruption is fixed in Windows 2012 and Microsoft has also released a hotfix for Windows 2008 and Windows 7.

ExtremeZ-IP 8.0.4 detects and avoids Microsoft disk corruption (also known as circular reference) regardless of whether the Microsoft Hotfix is installed or not. ExtremeZ-IP will no longer hang when a circular reference occurs. There are 2 new event log messages pointing to the location of a circular reference and the location of a junction point circular reference:

Corrupted Circular Reference
A circular reference in path ‘\\?\F:\\oneWay\hello\world\hello‘ has been detected and avoided.  The physical disk is very likely corrupted.  The command line utility ‘chkdsk’ should be run with the ‘/f’ option at your earliest convenience.

Junction Point Circular Reference
A circular reference in path
‘\\?\F:\\oneWay\hello\oneway_junction\oneway_junction1\oneway_junction2\junction_oneway‘ has been detected and avoided.  The use of Junction Points has created the circular reference.  The target of the Junction Point ‘\\?\F:\oneWay‘ will NOT be followed.

NOTE:If you use Windows Explorer to navigate to the location of the corruption and you don’t have the Microsoft Hotfix installed, your server will probably hang.

Microsoft has identified an NTFS corruption issue that can cause a Windows 2008 server to freeze or hang. The specific corruption that causes the problem is a multi-level circular NTFS reference that Windows self-healing cannot fix. The OS hang caused by the corruption is fixed in Windows 2012 and Microsoft has also released a hotfix for Windows 2008. See Application freezes when an NTFS volume contains a circular directory reference in Windows 7 or Windows Server 2008 R2 for more information from Microsoft or to download the hotfix.

Note that this hotfix does not actually prevent the corruption nor does it fix it. The hotfix will only prevent the OS hang and mark the filesystem as dirty. Once the files system has been marked dirty the next time the server is rebooted an automatic chkdsk will be run and the problem will be permanently fixed.

This bug affects ExtremeZ-IP more than other services because of the way the Mac and therefore the AFP protocol deals with files. Internally the Mac does not use file names or paths to keep track of files, instead it uses a 32 bit numeric file ID to refer to files. This is what allows Mac aliases to continue to work even when the original file is moved. ExtremeZ-IP maintains something called a mapping stream which is  a table that maps the Mac 32 bit file IDs to the native Windows 64 bit NTFS file IDs. When the Mac makes a request to open a specific file ID ExtremeZ-IP translates the request and converts it to an NTNative command to open the file using the NTFS ID.

File ids are not just used by Finder aliases but most Mac applications also use aliases internally to keep track of their open files as opposed to working directly with file paths. Most Windows applications and services on the other hand open files by path and not ID. That is the main reason ExtremeZ-IP is much more likely to encounter the bug than many of the other higher level services. That being said other services that need to do low-level file access such as defragmenters and anti-virus scans are also likely to encounter the same problem; however, in general those services do not access the file system nearly as frequently therefore ExtremeZ-IP is likely to hit the corruption first.

The specifics of the corruption are that there is an NTFS ID  that  has above it an NTFS parent ID  which points back to that same ID. If it is single level circular reference (NTFS ID xxxx has a parent ID whose ID is also xxxx) then Windows 2008 self-healing was always able to auto fix it. If on the other hand it is more deeply nested such as a->b->c->a then without the hotfix the kernel could go into an infinite loop and the server would hang.

The reason that the ExtremeZ-IP hangs is because there is a thread that is asking the OS to open a file and that file has circular reference. Once that happens the thread goes into an infinite loop in the kernel. ExtremeZ-IP has as a check that if a thread takes more than 300 seconds (5 minutes) to return it will attempt to cancel it. After 5 minutes we attempt to kill off the stuck thread but by then it is too late. The other ExtremeZ-IP threads which need to do kernel tasks are all backed up behind that single thread and the service can’t even get enough work done to shut down the stuck thread. More information about ExtremeZ-IP stalled thread handling can be found in the following article: http://support.grouplogic.com/?p=3787.

In order for Mac users using Kerberos to access SMB/CIFS reshares through ExtremeZ-IP delegation must be enabled in Active Directory. If your environment requires Kerberos authentication, you will need to update the Active Directory computer object for any Windows servers that are running ExtremeZ-IP. The ExtremeZ-IP server must be given permission to present delegated credentials to the SMB server on behalf of your users.

NOTE: When you set up a user’s profile Home folder in Windows Active Directory and Users, you need to use the server’s domain name (of the EZ-IP server domain) instead of its ip address in order for the network Home directories to work with Kerberos for Mac OS 10.6 clients.

1. In Active Directory Users and Computers, locate the Windows server or servers that you have ExtremeZ-IP installed on. They are commonly in the Computers folder.
2. Open the Properties window for the ExtremeZ-IP server and select the Delegation tab.
3. Select “Trust this computer for delegation to specified services only”.
4. Select “Use any authentication protocol”, this is required for negotiation with the SMB server.
5. You must now add any Windows servers or NAS devices that you would like your users to be able to access through reshare. Click Add… to search for these Windows computers in AD and add them. For each, you will need to select the “cifs” service type only.

Note: It may take 15 to 20 minutes for these changes to propagate through the Active Directory forest.

Cause:

ExtremeZ-IP uses Bonjour to allow Mac OS X users to see volumes in the Connect to Server dialog and print queues in the Print Center.

As of ExtremeZ-IP 8.0.1, version 3.0.0×10 of the Windows Bonjour Service is required, so this error will occur if an old version of the service is already installed on the server.

Resolution:

Option A: If Bonjour is not required, you can set ExtremeZ-IP not to use it. In the ExtremeZ-IP Administrator utility, click the Settings button. Select the Service Discovery tab and uncheck both the File and Print checkboxes for Bonjour.

Option B: If Bonjour is required, please open a new support case here.

Introduction

ArchiveConnect is fully compatible with ExtremeZ-IP 8.0’s new Network Reshare capability. This feature expands the options for giving Macs access to archive volumes on SMB accessible storage and also provides an excellent workaround for known issues with Mac clients running OS X 10.6.7 and later accessing SMB/CIFS archive volumes.

Network Reshare and ArchiveConnect provide a solution for accessing file archives on NAS storage

Due to an issue in Mac OS X 10.6.7 and later, Macs connecting to SMB accessible archive volumes on file servers or NAS storage are not able to properly recall files. This issue is fully detailed in this related knowledge base article.

By utilizing ExtremeZ-IP Network Reshare to make file archives, previously only available through SMB/CIFS connections, available to Macs using the standard AFP file sharing protocol, this issue can be avoided and Mac file recall behavior is properly managed by ArchiveConnect over the AFP connection.

Additional ArchiveConnct features included in ExtremeZ-IP also provide advantages to using AFP Network Reshare vs. using direct SMB access from Mac clients. An example is a configurable color label that indicates which files shown in the Finder are currently offline.

NetApp specific benefits to using ArchiveConnect with Network Reshare volumes

Before ExtremeZ-IP 8.0 with Network Reshare, Mac SMB access to NetApp archive volumes required the “Assume all SMB files are offline” setting to be configured in ArchiveConnect. This is not necessary when they are reshared through ExtremeZ-IP, so Mac users retain the ability to see thumbnail icons and quick look previews for files that are already online.

Introduction

Prior to the release of version 8.0, ExtremeZ-IP supported Mac AFP access to Microsoft Distributed File System (DFS) file shares in several ways. Traditional ExtremeZ-IP DFS support requires one or more DFS namespaces to be added to the DFS tab in the ExtremeZ-IP Administrator’s Settings window. Then, Mac clients must be set up with one of the following options:

• - The “Zidget” Dashboard widget – Used to browse DFS namespaces and mount specific resources within them.
• - The ExtremeZ-IP “DFS Client” application – Used to allow mounting of DFS volumes in the Finder and browsing of the related DFS namespace, similar to the experience Windows presents to users.
• - Manual modification of the Mac’s “auto_master” file – Provides the same experience as the DFS Client option, but requires editing a standard Mac config file rather than installing client software.

All of these options require client side software or changes on each Mac that requires access to DFS.

ExtremeZ-IP 8.0’s Network Reshare feature introduces an additional option for providing Macs with access to DFS resources. Network Reshare allows ExtremeZ-IP AFP file volumes to give access to folders located on other servers and NAS devices on your network. Macintosh clients continue to connect to ExtremeZ-IP using the standard AFP file sharing protocol, while ExtremeZ-IP utilizes the SMB/CIFS file sharing protocol to access files that are requested by Mac users from remote servers and NAS systems. By doing so, Mac users retain all the benefits of AFP file sharing while gaining access to resources that have traditionally only been available through SMB/Windows file sharing.

DFS shares can be configured as ExtremeZ-IP Network Reshare volumes. DFS target resolution simply occurs in the SMB reshare communication layer and Macs are able to seamlessly browse and access the reshared DFS resources presented in a standard AFP volume. No Mac client-side software or changes are required. Macs simply connect to ExtremeZ-IP AFP Network Reshare volumes in the Finder and can immediately browse the DFS namespace.

For more details on Network Reshare, see our Configuring Network Reshare support in ExtremeZ-IP knowledge base article.

Limitations

ExtremeZ-IP Server acts as DFS client
When hosting a Network Reshare DFS volume, the ExtremeZ-IP Windows server makes requests for resources located in DFS namespaces on behalf of the the Mac client. From the perspective of DFS, the Windows server itself is the client, not the actual Mac user making the request. For this reason, all DFS target selection and site costing will be negotiated for the Windows server, rather than the Mac client.

All Network Reshare communication is routed through the ExtremeZ-IP Windows server
Network Reshare routes all communication between your Mac clients and your DFS namespaces through the Windows server where ExtremeZ-IP is installed. This requires an extra network hop compared to the Mac client accessing DFS targets directly. For the best possible performance, it is recommended that ExtremeZ-IP is installed on a server with the fastest available NICs, and ideally this server has one or more NICs dedicated to communicating with the servers, NAS, or DFS namespaces being reshared.

ExtremeZ-IP Network Reshare feature and Network Reshare DFS volume configuration

For full details on configuring your ExtremeZ-IP server for Network Reshare and instructions on setting up a Network Reshare DFS volume, please see our Configuring Network Reshare support in ExtremeZ-IP knowledge base article.

Introduction

ExtremeZ-IP has traditionally only included the ability to share files and folders located on the Windows server where ExtremeZ-IP is installed, or on storage that is directly attached to that server. A folder within this local storage can be selected as an ExtremeZ-IP volume and made available to Macintosh users as a standard Mac AFP file share.

With the introduction of “Network Reshare” in version 8.0, ExtremeZ-IP now includes the ability to create file share volumes that point to folders located on other servers and NAS devices on your network. Macintosh clients continue to connect to ExtremeZ-IP using the standard AFP file sharing protocol, while ExtremeZ-IP utilizes the SMB/CIFS file sharing protocol to access files that are requested by Mac users from remote servers and NAS systems. By doing so, Mac users retain all the benefits of AFP file sharing while gaining access to resources that have traditionally only been available through SMB/Windows file sharing.

ExtremeZ-IP Network Reshare allows access to both standard SMB/CIFS file shares, as well as Distributed File System (DFS) file shares. More details on Network Reshare of DFS resources can be found here.

A common use case: AFP access to NAS storage

A common real world Network Reshare use case involves Mac access to NAS storage, such as NetApp NAS systems. Most NAS systems do not include the ability to host AFP file shares. Mac users are left with no choice but to connect to NAS file shares using the native OS X SMB client. This typically results in suboptimal file browsing, transfer, and search performance, along with frequent Mac application incompatibilities, file name issues, file corruptions, etc. Using Network Reshare, file shares on NAS systems can be made available to Macs through a Windows server running ExtremeZ-IP. Macs connect to ExtremeZ-IP AFP file shares and ExtremeZ-IP interfaces with the NAS system through the NAS’s existing SMB/CIFS file shares. In this way, incompatibilities and issues on the Mac side are addressed by allowing native AFP access and ExtremeZ-IP’s uses Windows server-side SMB access to NAS storage, which provides improved performance and throughput compared to Mac SMB client access. As a result, the performance of Mac AFP file share access though ExtremeZ-IP to NAS storage is most often better than that same Mac accessing the same NAS files directly over SMB.

Requirements

• - Windows 2003 or Windows 2008 Server (including R2 versions)
  • - If using Windows 2008 R2, make sure to install this MS hotfix: http://support.microsoft.com/kb/2647452
• - ExtremeZ-IP Server 8.0 or later
• - ExtremeZ-IP trial license or Enterprise License Program (ELP) license

The Network Reshare capability allows a single ExtremeZ-IP server to give AFP file access to many additional file servers or NAS systems. This feature is only enabled in ExtremeZ-IP trials and on ExtremeZ-IP Enterprise License Program (ELP) annual subscription licenses. This licensing option allows ExtremeZ-IP to be installed on an unlimited number of servers in your enterprise, as well as to create Network Reshare volumes.

Recommendations

ExtremeZ-IP Server Network Interface Card Performance
Network Reshare routes all communication between your Mac clients and your file server or NAS storage through the Windows server where ExtremeZ-IP is installed. Installing ExtremeZ-IP on a server with the fastest available NICs, and ideally one or more dedicated NICs for communicating with the servers or NAS being reshared, will result in the highest level of performance.

Windows 2008 and SMB v2
While Network Reshare is compatible with Windows 2003 and 2008, the SMB v2 protocol supported by Windows 2008 consistently demonstrates higher levels of performance. Installing ExtremeZ-IP on a Windows 2008 server and using remote storage that is running Windows 2008, or a NAS operating system that supports the SMB v2 protocol, will result in the best file sharing throughput for Mac users.

Kerberos for ExtremeZ-IP Network Reshare
In order to support Kerberos logins you will need configure Active Directory to “Trust this computer for delegation”. More information can be found in the following KB article: http://support.grouplogic.com/?p=4164

Limitations

No support for index-based filename search and full content “Network Spotlight” search

To support indexed filename search, ExtremeZ-IP requires file system notifications provided by Windows in order to keep its search index up to date when files change. These notifications are not available over the SMB connection ExtremeZ-IP uses to access file servers and NAS systems being reshared. For this reason, index-based filename search is disabled on Network Reshare volumes.

To support full content “Network Spotlight” search, ExtremeZ-IP utilizes the Window Search index maintained by the Windows Search service on the server ExtremeZ-IP is installed on. Currently, only indexing of files on the local server storage is compatible with ExtremeZ-IP. For this reason, full content Network Spotlight search is disabled on Network Reshare volumes.

Macs searching ExtremeZ-IP Network Reshare volumes will receive search results based on filename, but searches will take additional time to complete compared to searching indexed local volumes.

Finder color labels may be removed when saving/overwriting a file on an ExtremeZ-IP Windows 2003 Network Reshare volume
If ExtremeZ-IP server is installed on Windows 2003, opening and then saving an existing file that exists in a Network Reshare volume may result in the Finder color label on that file being removed.

Initial Network Reshare configuration

ExtremeZ-IP runs as a standard Windows service on the Windows server it is installed on. By default, the ExtremeZ-IP service runs in the context of the Windows local SYSTEM account. By acting as this account, ExtremeZ-IP has access to the files and folders in ExtremeZ-IP volumes that are located directly on the server’s storage. When ExtremeZ-IP is configured with Network Reshare volumes, it also needs access to the files and folders on the remote file servers and NAS devices that are being reshared. In order for ExtremeZ-IP to be allowed access to these files, the ExtremeZ-IP service must be reconfigured to run in the context of an Active Directory (AD) user account that has Administrator access to the local Windows server and Full Control access to any necessary file shares that exist on remote servers or NAS systems being reshared.

If you’re using Windows 2008 R2, ensure you’ve installed this Microsoft hotfix. It addresses an issue that is directly related to Windows functionality used by ExtremeZ-IP Network Reshare. Hotfix link: http://support.microsoft.com/kb/2647452

To configure Network Reshare:

1. Ensure you’ve upgraded to ExtremeZ-IP version 8.0 or later and have launched the ExtremeZ-IP Administrator application at least once and allowed the ExtremeZ-IP service to start up.
2. Create or identify an AD user account that will handle authentication for ExtremeZ-IP. This account will need Full Control access to any local or remote shared volumes as defined in NTFS or NAS device permissions. In addition, this user needs Full Control permissions to the C:\Program Files (x86)\Group Logic\ExtremeZ-IP folder. You should also add this user account to the local Windows server Administrators group. Ensure the AD account used is dedicated to this ExtremeZ-IP server, has a fixed password, and is not subject to group policies for password expiration.
3. Add the selected user to the Windows server’s local security policy: “Act as part of the operating system”. From Administrative Tools on the Start menu, open Local Security Policy. This policy is found under Security Settings -> Local Policies -> User Rights Assignment section. Double click “Act as part of the operating system” and add the chosen user. You may have to reboot Windows for this setting to take effect.
4. From the Services control panel, open the Extreme-Z IP File and Print Server for Macintosh service’s properties by right clicking on the service from the Services control panel. Select the “Log On” tab and choose the “This account” radio button. Configure the service to log on as the same AD service account used in step 3. Keep the Services control panel open. You will need it again in step 6.
5. Start the ExtremeZ-IP Administrator application. Click the Settings button and on the File Server tab, ensure the Enable Network Reshare support option is checked. Then click OK and Close the ExtremeZ-IP Administrator.
6. In the Services control panel restart the Extreme-Z IP File and Print Server for Macintosh service.

Network Reshare volume configuration

1. Launch the ExtremeZ-IP Administrator application.
2. Click the Volumes button and the then click Create.
3. Click On another server. If you are not shown an option to choose On another server, you may be running a standard ExtremeZ-IP retail license rather than the required Enterprise License Program (ELP) license.
4. Enter the UNC path of the SMB/CIFS file share that you would like to reshare as an ExtremeZ-IP volume, then click OK. This UNC path is in the typical \\servername\sharename format. An example is: \\nas.mycompany.com\myshareDistributed File System (DFS) UNC paths can also be entered for Network Reshare volumes. DFS target resolution will all occur in the SMB reshare layer and Macs will be able to seamlessly browse and access the reshared DFS resource. For more details on DFS with Network Reshare, see our Accessing DFS files using ExtremeZ-IP Network Reshare knowledge base article.
5. In the Volume Properties dialog, modify the Volume Name if desired and click OK.
6. If you receive an error stating that “The specified path is not available.” you may have entered an invalid UNC path, or the user account you selected in the Initial Network Reshare configuration steps above may not have Full Control access to this file share at this UNC path. If this is a Windows file share, ensure this user account has both “Sharing” and “Security” permissions to the file share.

We have tested the latest versions of the following products and found that they are compatible with OS X Mountain Lion:

activEcho (tested 2.5)
ArchiveConnect (test 1.2.5)
ExtremeZ-IP (tested 8.0.1)
MassTransit (tested 7.2.7 Web Client)

mobilEcho is unaffected since it consists of server and mobile device components.

If you have any questions or find any issues with our products, please email us at support@grouplogic.com.

For information on compatibility with the OS X 10.7 Lion release, please see http://support.grouplogic.com/?p=3538

Symptom: Event Viewer message reporting “Long delays processing Mac client commands have been detected. This could be an indication of a server hardware or operating system problem. Please see the following knowledge base article for further information”

ExtremeZ-IP is designed to log this event whenever Windows fails to respond to a request for more than 300 seconds. When this hang threshold is hit, ExtremeZ-IP will produce a dmp file (default setting) in order to trap forensic info about the state of the thread and types of requests leading into the stall.

There are two types of stalls:
1) Stalls that complete: Hangs that last more than 300+ seconds but eventually complete
2) Stalls that never complete: Here you will find the ExtremeZ-IP service may have hung or that the entire server operating system may have hung.

In most cases the underlying problem is related to outdated firmware/drivers, a poorly written kernel driver, resource constraints (bottlenecks) or poor disk health. If you haven’t recently checked disk health, running chkdsk with the /f switch and updating controller card drivers has been found to resolve a majority of cases.

Note: chkdsk in Read-Only Mode Does Not Detect Corruption on NTFS Volume. See http://support.microsoft.com/kb/283340

If chkdsk finds and fixes an error such as “Breaking links between parent file xxxxx and child file xxxxx” then your disk was suffering from what is known as a circular reference and you should no longer have the long delays.

UPDATE: Microsoft has released a hotfix that will prevent the hang when accessing a circular directory reference. In addition once the operating system detects the circular directory reference it will mark the disk as needing to be repaired at the next server reboot. See the following KB articles for more information: http://support.microsoft.com/kb/2782476 or http://support.grouplogic.com/?p=4207.

If you would like us to review your logs to see if we can help narrow down the problem, please open a support case and upload supporting files as described below:
- Open a support case online (include description/observations): http://support.grouplogic.com/request
- An automated email will be sent back to you with a case number so that you can upload the following files to our support site:
a) ExtremeZ-IP Logs folder: Right-click the folder C:\Program Files\Group Logic\ExtremeZ-IP\Logs and select Send To –> Compressed Folder
b) any dump files (*.dmp) you find in: C:\Program Files\Group Logic\ExtremeZ-IP
c) Generate a System Information report: At Start –> Run, type msinfo32 to launch the tool. Then select File –> Save to save the .nfo file.
d) Export application and system event logs as evt/evtx file

Zip the above files as case#.zip and upload using a browser:
http://mtweb.grouplogic.com
User: supportfiles
Password: $grouplogic123$

Note: If you are not running the latest version of ExtremeZ-IP, please upgrade as the latest release may provide better diagnostics/logging: http://support.grouplogic.com/ezlatest