Showing posts with label ExtremeZIP. Show all posts
Showing posts with label ExtremeZIP. Show all posts

Tuesday, September 16, 2014

Windows 2008 Server: Files Locked for Editing

We have been receiving numerous reports that Mac clients were unable to edit files when opened from a Windows 2008 server share.  Clients would receive the following message when they attempted to open files:

If the user copied the file to their desktop they were able to open it but as soon as they saved it back they would get the same lock message.

The file lock issue existed regardless of whether or not the user connected via SMB or AFP (using ExtremeZIP).  Restarting ExtremeZIP and the server did not resolve the issue; nor did closing all open file connections.

We discovered the following work-around:
  • On the server open Control Panel/Folder Options/View
  • Put a tick in "Show Hidden Files and Folders"
  • Remove the tick in "Hide protected operating system files (Recommended)"
  • Apply the changes
  • Go to the folder with the locked file
  • Look for a temp file with a "~$" in front of the file name.  Examples: ~$filename.xls or ~$filename.xlsx
  • Delete the temp files
 After deleting the temp files the user could open the file without a problem.

Note: the issues we were seeing were occurring with Excel files.  I don't know if this same procedure will work if you are seeing the file lock with other file types but it is worth a go.

Friday, March 9, 2012

ExtremeZIP Optimisation and General Settings

We have received several requests as to the best way to optimise performance of Windows servers running ExtremeZIP file sharing for Apple clients.  In particular many sites see the following warnings in their ExtremeZIP logs (Windows 2003 server):


If you see these warnings, or even if you don't but still want to make sure your system is running as smooth as possible, the first thing you should do is read this KB article from Group Logic:

http://support.grouplogic.com/?p=1544

It goes into detail about the registry settings that need to be tweaked in order to get the best out of ExtremeZIP.  The KB is from 2009 but the registry changes are still applicable on 2008 R2 servers.  Here is an example of the registry changes to make:


It is also recommended that on Windows 2003 server you Maximize Data Throughput for Network Applications instead of "File Sharing".  To do this follow these steps:

  1. Right-click on My Network Places and select "Properties"
  2. Right-click on your NIC and select "Properties"
  3. Highlight "File and Print Sharing for Microsoft Networks" and click the "Properties" button
  4. Enabled Maximize data throughput for network applications 
General ExtremeZIP Settings

We have found that the following setup works well for most locations (your mileage may vary).

Launch ExtremZIP Administrator and click on the "Settings" button; select the "File Server" tab.


Put ticks in the "Allow Encrypted Logins" and "Allow Kerberos Logins" only.

Click on the "Security" tab.

In order to have ExtremeZIP support Unix and more granular ACLs on volumes you must supply an AD account.

  1. Put a tick in "Global Catalog"
  2. Enter an account that has domain access.  It is a good idea to use a service account that has a password set to never expire.  Add the account in the format of "yourdomain\account.name"
  3. Enter the account password
  4. For "Domain" enter the FQDN of your domain
  5. For "Permissions" use the the settings in the above example.  You generally don't want your Mac clients to be able to change folder permissions so remove the tick from "Allow Mac clients to change permissions"
  6. If you like you can select one of the tick boxes under "Show only accessible:"  If you check the "Folders" option, users will see only folders that they can access. If you check the "Files" option, users will only see files they can access
  7. Under "Other Options" you can "Allow remote administration of server" if you want Windows admins to be able to use the remote admin features of ExtremeZIP (click the "Help" button for more details)
  8. By putting a tick in "Notify Mac clients of password expiration in XX days" your Mac clients will see a password change notification when they connect to an ExtremeZIP enabled share.  Note: they can not change their password directly from the expiration warning dialogue box.
Click on the "Search" tab.


Search settings should be customised for your environment.  If you put a tick in "Index volumes for search" ExtremeZIP will create an index of all the files on your ExtremeZIP volumes.  This allows Mac clients to do rapid searches of files/folders using the ExtremeZIP index and does not impact the server drives.  However, this only applies to searches performed at the root level of a volume.  Searches performed in sub-folders will use standard Windows enumerated searching (more disk intense).

Keep the default "Maximum search index cache size" at 20MB.

"Lazy Indexing" limits the amount of system resources available for indexing and is recommended for servers under high load or with considerable I/O traffic.

"Automatically rebuild sparse indexes" is a maintenance function of ExtremeZIP that cleans up the indexes when 1/3 of the records are stale. 

If you want to enable Spotlight searching put a tick in the "Support Spotlight Search" box.

Click on the "Filename Policy" tab.


If you are working in a mixed environment where Mac and PC users must share files it is recommended that you use ExtremeZIP's filename policy to force Mac clients to create files/folders that are compatible with Windows systems.

To enable filename policy enforcement put a tick in "Enforce Filename Policy".

"Apply policy to all volumes" will enable the policy on all files/folders in newly created volumes.  Legacy volumes and existing files/folders will not be affected.

If you want the user to simply be warned of naming violations un-tick "Reject policy violations..."

Under "Do not allow:" you can select what characters and name lengths are acceptable.

Put a tick in "Characters illegal in Windows file or folder names" if you want to exclude filenames that contain characters not allowed in Windows.  The characters are / ? < > \ : * |  trailing spaces and trailing full-stops.

Put a tick in "Characters that will not display in Windows Explorer" to exclude names that can not be displayed in the font used by Windows Explorer (the default is Tahoma).

By limiting the file/folder names to 254 characters you can ensure compatibility with Windows systems.  You may also enable the 254 character limit for paths as well.

Click on the "Service Discovery" tab.


For "Server Name" enter the server name as you want it to appear to Mac clients.

If you are in a standard Windows/Mac environment you only really need to tick the "File" and "Print" boxes next to "Bonjour" to make the ExtremeZIP enabled Windows server visible in a search from Mac clients.  The rest of the protocols only need to be enacted if you use them at your location.

Note: there should be no need to use AppleTalk unless you have OS9 clients or AppleTalk printers.

The latest information, knowledge base articles and manuals can be found on the GroupLogic site.

Monday, February 6, 2012

Single-Sign-On (SSO) not working for Snow Leopard clients connecting to a Windows server running ExtremeZIP

We received a report from an office that three of their Windows 2003 servers running ExtremeZIP were not allowing SSO connections from AD bound Snow Leopard Macs.

After a good deep-dive into the problem, including packet traces and help from Group Logic, we resolved the problem.  Here are the steps we took:

Make sure the Mac clients are using the FQDN to connect to the ExtremeZIP AFP volume on the server.  Short names should not be used (in Lion you must use the FQDN or you get an error).

Check that the time on the server, clients and DC match.  One of the servers' clock was out by six minutes (max Kerberos time skew is five minutes).  When the time was set correctly Lion clients were able to log in.

Check that the Server Principle Name (SPN) of the servers is correct; if they are not then authentication can fail.  Read more about SPNs here.

To check the SPN on a Windows 2003 server you must first download and install Windows Server Support Tools.  You can get them here.

After you have installed the tools go to Programs/Windows Server Support Tools and launch the app- it will open a command line.

Both the long and the short SPN for the AFP protocol need to exists for your servers:
afpserver/servername.company.com
afpserver/servername

To display the SPNs from the Support Tools command line type "setspn servername"

You should see both the FQDN and the short name.  If one is missing do the following:

- To add the long name: setspn -a afpserver/servername.company.com servername
- To add the short name: setspn -a afpserver/servername servername

We also found that although the Snow Leopard clients were authenticating users correctly, they were not generating a Kerberos ticket at login (you can verify this by going to the Ticket Viewer.app located in System/Library/Core Services).  After manually generating a Kerberos ticket, SSO worked.

To force a Snow Leopard client to generate a Kerberos ticket at login follow the instructions in this Apple KB article.

After carrying out each of these steps, the Snow Leopard clients were able to get SSO to the ExtremeZIP enabled servers.

Although it wasn't necessary in this case, make sure you update ExtremeZIP to the latest version

Thursday, July 7, 2011

Windows 2008 server and ExtremeZIP: AFP Shares appearing as read-only to Mac users

After moving data from a Windows 2003 server to a Windows 2008 server via robocopy Mac users were unable to write to some folders.  The files and folders appeared to copy correctly, along with the permissions and Windows users could access the folders without a problem.

The Windows 2008 server is running ExtremeZIP and the problem only occurs if the clients connected via AFP- SMB connections were fine.  The problem affected both AD bound and unbound Macs.

FIX: it turned out that file permissions didn't fully copy (or perhaps robocopy doesn't have the flags that Windows 2008 Server requires).  Folders that the Mac users could only see as read-only were missing a tick in "Delete subfolders and files and folders" in the Advanced folder settings.

Go to the security properties of the folder and click on the "Advanced" tab


 Highlight the user/group that you want to check permissions on and click "Change Permissions"



Highlight the user/group again and click "Edit"


Make sure there is a tick in "Delete subfolders and files"


Make sure you propagate the permissions to all child objects.