Posts Tagged ‘ExtremeZ-IP’

GroupLogic product compatibility with Windows 8

Wednesday, April 3rd, 2013

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

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

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

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

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

NTFS Circular Reference

Tuesday, February 5th, 2013


Microsoft has identified an NTFS corruption issue that can cause a Windows 2008 server to freeze or hang. This article explains what the corruption is, some ways that we have been able to recreate the corruption in our test lab and potential workarounds to prevent the corruption from causing the server to freeze. If you don’t care about the details you can just download a hotfix from Microsoft that solves the problem:


The specific corruption discussed here is a multi-level circular NTFS reference that Windows self-healing cannot fix. An example of a circular reference is an NTFS ID that has above it an NTFS parent ID that 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 is able to auto fix it. If on the other hand it is more deeply nested such as a->b->c->a then without a Microsoft hotfix the kernel could go into an infinite loop and the server would hang.

The primary way that GroupLogic has been able to reproduce the problem is using a Mac client that has two different windows open to the same folder hierarchy on the server. If a user drags a folder from one window into one of the folders below it in the other window the circular reference will be created. In other words moving the folder “a” from one window into folder “c” of a/b/c in the other window. Although less likely, the circular reference can also be caused by two different users moving folders within a very short period of time. An example of that would be Fred moving folder “a” to x/y/z at approximately the same time Sally moves folder “x” to a/b/c.

Once there is a NTFS multi-level circular reference the reason that the ExtremeZ-IP hangs is because when ExtremeZ-IP asks the OS about that folder the kernel goes into an infinite loop. ExtremeZ-IP does have built-in safeguards so that if an operation takes a thread more than 5 minutes to complete ExtremeZ-IP will attempt to cancel it. With a circular reference after 5 minutes ExtremeZ-IP does attempt to kill off the stuck thread, unfortunately 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:


The hotfix from Microsoft should solve all known circular reference issues in the NTFS driver and is the recommended solution to the circular reference problem. See their KB article: for more information from Microsoft about the hotfix.

According to Microsoft the kernel hang caused by the corruption was supposedly fixed in Windows Server 2012. Although we have been able to reproduce the issue using Windows Server 2012 in our own labs, we have had any reports from the field of that involved Windows Server 2012. Because the issue many not be completely resolved in Server 2012 we recommend that you upgrade those servers to the latest version of ExtremeZ-IP.

ExtremeZ-IP 8.0.4 and later attempts to detect and avoid Microsoft disk corruption (also known as circular reference) regardless of whether a Microsoft Hotfix is installed or not. Unfortunately sometimes just checking the file system for the circular reference is enough to hang the kernel. In cases where we can identify a circular reference ExtremeZ-IP will log an event log message pointing to the location of a circular reference.

In ExtremeZ-IP 8.0.5 and later not only do we attempt to detect existing corruption but we also prevent users from moving parent folders into child folders for regular Windows drives.

With mount points it can be much more difficult to determine from an NTFS ID the actual path to an item therefore we were not able to come up quickly with a way to solve the issue. The ExtremeZ-IP development team continued to work on this and an upcoming ExtremeZ-IP 8.0.6 release that is currently in Quality Assurance testing will extend the blocking behavior to mount points. When this is released all known ways of creating the circular reference from a Macintosh client will be blocked by ExtremeZ-IP.

redirected (was Microsoft NTFS Circular Reference Hotfix)

Wednesday, January 30th, 2013


Configuring Kerberos for ExtremeZ-IP Network Reshare

Wednesday, November 7th, 2012

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.

ExtremeZ-IP has detected an incompatible version of the Bonjour Service

Tuesday, September 11th, 2012


ExtremeZ-IP uses Bonjour service advertisements to allow OS X client computers to see ExtremeZ-IP volumes in the Connect to Server dialog and print queues in the Print Center.

As of ExtremeZ-IP 8.0.1, version 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.


Option A: If Bonjour service advertisements are not required, you can set ExtremeZ-IP not to register with the Bonjour service. 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 service advertisements are required and you have an older version of Bonjour already installed on your server, perhaps by another software package that also uses Bonjour service advertisement, you will first need to upgrade to ExtremeZ-IP 8.0.5, then determine if your other software package is compatible with Bonjour version

To switch to using Bonjour, open a command prompt and navigate to

“C:\Program Files (x86)\Bonjour” (This is where Bonjour is installed by default)

Then enter the command

mdnsresponder -remove

This will remove the installed service for the legacy Bonjour installation. Within a few minutes ExtremeZ-IP will automatically install a new Bonjour service for our included Bonjour installation.

If the ExtremeZ-IP service advertisements do not begin within a few minutes, a reboot of the server may be required.

If these steps do not resolve any issues, please open a new support case here.

Using ArchiveConnect with ExtremeZ-IP Network Reshare

Wednesday, June 6th, 2012


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.

Accessing DFS files using ExtremeZ-IP Network Reshare

Wednesday, June 6th, 2012


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.


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.

Configuring Network Reshare support in ExtremeZ-IP

Wednesday, June 6th, 2012


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.


  • - Windows 2003 or Windows 2008 Server (including R2 versions)
  • - 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.


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:


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:

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: \\\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.

GroupLogic Product Compatibility with Apple’s OS X 10.8 Mountain Lion

Friday, June 1st, 2012

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 contact us at

For information on compatibility with the OS X 10.7 Lion release, please see

Event Viewer message reporting “Long delays processing Mac client commands have been detected.”

Wednesday, November 9th, 2011

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

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 this error. See the following KB article for more information:

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):
- 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 and upload using a browser:
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: