Showing posts with label Mac. Show all posts
Showing posts with label Mac. Show all posts

Thursday, June 30, 2016

Excel 2016: Spell Check Causing Applicaiton Lock

Office 2016 has been very unstable.  Microsoft is tacitly admitting as much by releasing a steady stream of updates.

One of the persistent problems has been the spell check function in Excel.  Simply put, when you attempted to spell check a worksheet, the application would lock-up.  After a failed spell check, quitting the application normally was impossible; the only way to shut Excel down was to Force Quit it.

The spell check issue persisted despite the ongoing MS updates.  I myself experienced the problem on two separate MBPs and after no less than six removals and reinstalls.  Eventually I found a procedure that seems to have resolved the spell-check nightmare:
  • Drag all MS Office 2016 documents to the trash
  • Go to ~/Library/Group Containers and delete the following files
    • *.office
    • *.ms
    • *.officeosfwebhost
  • Empty trash
  • Restart and re-install Office 2016 (applying all updates)
 After performing the above steps Excel spell check is working.  At least until the next MS update.

Sunday, November 8, 2015

Mac OS: Desktop Icons Not Appearing

We encountered a 10.9.5 Mac where the user's desktop icons were not displaying.  They showed up in their Desktop folder but not on the desktop itself.  Attempting to add a file/folder resulted in it being placed into the Desktop folder but not on the desktop.

The simple fix was to go to View/Clean Up and then all the icons appeared.


Tuesday, October 13, 2015

Unable to SSH into a remote Mac: ssh_exchange_identification: Connection closed by remote host

When attempting to SSH into a remote Mac running 10.10.5, Terminal returned the following error:

ssh_exchange_identification; Connection closed by remote host

On the target machine we checked the Console log and found that during each SSH login attempt an error would appear in the log:

sshd: fatal: /var/empty must be owned by root and not group or world-writable.

We changed the ownership on the /var/empty folder:

sudo chown -R root:staff /var/empty

And we were then able to SSH to the remote computer.

Thursday, March 12, 2015

Items can't be copied to a Mac because there is not enough free space, even when disk information shows plenty of free space

When attempting to copy 50GB of data onto a Mac Air that was reporting 210GB of space available the copy failed on an error "not enough free space available".

The root cause was Time Machine backups utilizing the local drive.  Even though the person never used Time Machine it was still enabled and apparently backing up to the local HDD.  Turning off Time Machine freed up the space and we were able to copy the data successfully.

Looking under  System Information/System Report/Storage we saw the backups taking up a massive amount of space; only 4kb was left available.

You can also disable Time Machine from the command line:

sudo tmutil disablelocal





 



Wednesday, March 11, 2015

After migrating a Mac user's profile, Dropbox fails to open: keeps asking for permissions

After migrating a user's profile and changing ownership on their home folder the user was unable to log into Dropbox after logging in.  The users received an error:

"Dropbox needs to change permissions for the Folder: ~/Users/.dropbox  Type in your password to allow this."

Typing in the user name and password did nothing.  The user was then presented with another window that said, "Couldn't start Dropbox.  This is usually because of a permissions error.  Storing your home folder on a network share can also cause an error."

The solution that worked for us was to remove the hidden "./dropbox" folder from the root of the user's home folder.  You can do this from terminal by typing:

sudo mv ~/.dropbox ~/.Trash

Or you can do it from the GUI if you turn off hidden folders.

I have also heard that you should delete the DropboxHelperTools folder although that wasn't required in our situation.

sudo mv ~/DropboxHelperTools ~/.Trash


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.

Tuesday, September 9, 2014

WiFi Network Dropping Packets on a Mac

A MacBookPro running 10.9.4 was experiencing a problem where it would suffer constant connection drops on some WiFi networks with upwards of 70% packet loss.  Cable connections were fine and not all WiFi connections displayed this problem.

The WiFi router was replaced and a separate WiFi access point was tried and still the drops continued.  Other computers connected to the same WiFi network did not have this problem.

We resolved the issue by following these steps:
  • Turn on WiFi on the Mac
  • Open System Preferences/Network
  • Highlight the WiFi connection and click on the "Advanced" tab
  • Click on the "Wi-Fi" tab
  • Remove the problematic network.  It might be a good idea to remove ALL the saved networks as long as the user knows the passwords for them!
  • Click "OK" and then "Apply" to apply the changes
  • Open Keychain Access
  • Highlight the "Login" keychain
  • Search for "Airport"
  • Find the "AirPort network password(s)" that are associated with the problem network and delete them.  Note: there are normally two per network, "System" and "Local Items" Keychains
  • Restart
  • Log into the WiFi network and enter the authentication details when prompted
After removing the shared networks and deleting the items from the Keychain the packet loss stopped and normal WiFi connectivity was restored.


Thursday, July 10, 2014

Outlook 2011: Junk Mail Protection Greyed Out

According to this Microsoft KB, people using Outlook 2011 and Exchange 2013 are unable to access the tool-bar item "Junk e-mail protection" because the item is greyed out.


However, one of our clever system admins in Warsaw discovered that if you first open Outlook Preferences and then go to Tools in the menu bar, Junk E-mail Protection magically comes back.


I haven't done thorough testing but it appears that using this work-around does enable client-side Junk mail filtering configuration.

Thursday, September 26, 2013

Casper not Correctly Setting Software Update Server

We have received hundreds of reports that 10.8.4 Macs have been updating themselves to 10.8.5 even if they are managed by a local Software Update Server and the 10.8.5 update has not been authorized.

Although we do not have a single root cause, the problem definitely lies within the configurations being distributed (or not) by Casper.  Based on the conversations we have been having with Apple, Jamf and our agencies here are a few recommendations for your Casper set up:
  • Set the Software Update Server through MCX for 10.6.8 Macs or a Configuration Profile for 10.7 and 10.8 Macs
  • In the "Overwrite Default Policy Settings" area of any Software Update policy you have created use the pull-down next to "Software Update Server" to select "Each Computer's Default Server"
  • Put a tick in "Set Server System Wide" (under Settings/Servers/Software Update Server) after you have done the above should correctly set the SUS for the managed clients on your subnets
  • You could also set the default SUS in any Network Segments you have created (Settings/Update Network Segments) and it should set the correct SUS if you run a policy with just "Set Server" ticked in Packages/Set Server.

If you want Casper to collect the SUS a client is pointed to add the Extension Attribute "Apple Software Update Server" and replace the default script contents with:

#!/bin/sh

SWU=`defaults read /Library/Preferences/com.apple.SoftwareUpdate CatalogURL`

echo "$SWU"


Lastly if you want to brute-force the SUS settings to your computers, remove all references to the SUS from Casper policies, MCX, Configuration Profiles and Network Segments and deploy a script that contains these lines:

#!/bin/sh

defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL

defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://[your SUS server.yourCompany.com]:8088/index.sucatalog

killall Terminal

Monday, May 13, 2013

Change Mac hostname from Terminal

Sometimes I have found that changing the Mac's hostname from System Preferences/Sharing doesn't do the job.  In these cases it is best to change the hostname from Terminal:

sudo scutil --set HostName [new hostname]

Example: sudo scutil --set HostName LDNMAC-1234


Show hidden user Library folder in 10.7 and 10.8

I keep having to look this up because I can never remember the Terminal command:

chflags nohidden /Users/[user folder name]/Library

example: chflags nohidden /Users/tom.smith/Library

Saturday, March 2, 2013

High CPU usage with Lync and Outlook 2011

We have received numerous reports that having Lync and Outlook 2011 open at the same time is causing one, or both, of the processes to use 100% of the CPU.  This in turn causes Outlook to become unresponsive until you force quit either Outlook or Lync.  Having the applications open separately does not cause a problem- only when they are both open at the same time.

To troubleshoot the problem, open Lync, go to Preferences/General and put a tick in "Turn on logging for troubleshooting".  Restart Lync and then Open Outlook and Process Viewer.  Work normally until Outlook freezes and you see in Process Viewer that the CPU use for Lync and/or Outlook has spiked.

Close (or force quit) Outlook and Lync and open Console Viewer.

In Console Viewer, under Files/~/Library/Logs open the Microsfot-Lync-0.log.  Search the log for multiple (hundreds) of entries referencing the same e-mail address and having an "INFO" line of "FindOrCreateFakeContactModelForQuery"


Open Outlook and remove all references to the offending e-mail account.  This includes contacts and any auto-complete entries.

To clear the auto-complete entries, open a new mail and start typing the user's name; a box should open that displays the e-mail address; to the right will be an "X".  Click on the "X" to remove the entry.

Relaunch Outlook, open Lync and check that you no longer experience the high CPU problem.

When you are sure the problem has been resolved, make sure you turn off logging in Lync.


Friday, February 1, 2013

Safari Blocking Oracle 7.11.21 Plug-in: Can't Connect to Juniper VPN

The war between Apple and Java continues.  Apple is blocking the latest Java saying that it is susceptible to malware. 

We have received several reports that Mountain Lion clients are unable to contact the Juniper VPN launch page.  The users are presented with an error that says "Blocked Plug-in":


They may also be prompted that Java is out of date and that they should download Java:


They are then redirected to the Oracle download page.  Even after they download the latest Java, they will still see the "Blocked Plug-in" error.  The cause of this error appears to be Apple's anti-malware protection.

The only work-around we have found is to do the following:

Go to /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/

Type "sudo pico XProtect.meta.plist"

Look for the line "MinimumPlugInBundleVersion"










Note that the version is set to 1.7.11.22 but the latest version of Oracle Java is 1.7.11.21.  This prevents the browser from loading the current Oracle Java because it says the minimum version is .22 but the latest is currently .21

It is possible to edit the "MinimumPlugInBundleVersion" and change the minimum value to 1.7.11.21:






After making the change, save the file, restart Safari and go to the VPN page- you should be able to log in.

Not only is this affecting Juniper VPN but several of our other web-based Java apps.





  

Wednesday, November 7, 2012

Recon failed during the submit process. Could not recognize the JSS response

After upgrading to JSS 8.6 a site noticed that none of the Jamf binaries on the clients were being updated.

When we attempted to Recon the Macs again the process would fail with a message "Error enrolling computer.  Could not recognize the JSS response."

 
We would receive the same error no matter what method we used to get the computer into inventory: local Recon, Quick-Add Package, command line enrolment, etc.

From the screen-shot it would seem that the problem had to do with the client or server's certificate.  However, after renewing the JSS' certificate, double-checking that it was valid and that existing clients could communicate with the JSS we were at a loss to explain why Recon was failing.

The answer was both simple and completely crazy.  It seems that if there is a non-standard character in the "Display message to User:" field in Restricted Software it causes Recon to fail with the above mentioned error.

The text of the original message:  Este software no está permitido en la red corporativo

After changing "está"  to "esta" we were able to Recon computers normally.

How bizarre is that?

A big thanks to Derek at Jamf support for figuring out the problem.  We would have spent years hunting for a fix on our own.

Friday, October 19, 2012

10.7 and 10.8 Clients do not generate Kerberos tickets at login: FIX

(For information about forcing 10.6.x clients to get a Kerberos ticket at login see this Apple KB)

We have encountered a problem where Lion and Mountain Lion clients are not generating Kerberos tickets at login.  This causes problems with single-sign-on (SSO) to network shares as well as with Kerberos enabled applications like SAP.

Apparently Apple's latest version of Kerberos will not automatically request a ticket when a Kerberos enabled application launches.  Instead you must either go to Terminal and type "kinit" and enter your password or force a ticket to be generated at login using the following instructions.

Note: in order to correctly authenticate using Kerberos enabled applications like SAP your user name in AD and in the application itself must match.  This means that both your SAMAccount name and UPN in must be identical- including the case.  Many non-Microsoft instances of Kerberos are case-sensitive.

To generate a Kerberos ticket at login (10.7 and 10.8 clients):
  •  Open Terminal
  • Type "sudo -s" and authenticate as super user
  • Navigate to /etc/pam.d
  • Type "cp authorization authorization.bak" to make a backup of the authorization file
  • Type "pico authorization" to edit the file (you could also use vi or your favourite editor)
Find the line:
auth       optional       pam_krb5.so use_first_pass use_kcminit
Add the key "default_principal" to the end of the line. For example:
auth       optional       pam_krb5.so use_first_pass use_kcminit default_principal
  • Save the file
  • Restart and log back into the computer
  • Check that a Kerberos ticket has been generated by opening Terminal and typing "klist"

Friday, August 17, 2012

Troubleshooting Mac Binding and Authentication Problems: AD perspective

Ensuring a clean DNS and directory environment is key to resolving a host of problems, not all of them Mac specific.  Many binding, authentication and slow login issues can be traced back to incorrectly configured DNS, a missing subnet in Sites and Services or poor replication between domain controllers.

This post is designed to provide a check list of sorts for directory services administrators as they attempt to diagnose Mac and AD issues.  None of the steps listed here are designed for end-users or the Mac clients themselves- they are back-end checks for system administrators comfortable with DNS, DHCP and domain controller diagnostics using the command line.

Domain Controller Checks

The health of the local DC is a factor with Mac binding and post-binding authentication problems.  Many sites have ageing DCs with inadequate RAM and they may not be able to process authentication request properly.

Adding to the problem is the fact that pre-Lion Macs are only dimly site-aware.  This means that during the binding process they can attempt to connect to whatever DC they find that has a valid SRV record.  Thus, even if a local DC is brand new and functioning perfectly, Macs could still have binding problems because they are looking to a DC on a remote site that is not reachable or otherwise unavailable.

Steps can be taken on the client to force the use of the local DC: using a custom edu.mit.kerberos file and setting the local DC as the preferred domain controller during the binding process.  These procedures are detailed in other posts on this site.

From a Directory Services standpoint there are several checks that can be done to ensure that the DC is performing optimally.
  • Check the RAM.  1GB is generally not enough
  • Check the processor load to ensure the CPU is not consistently running over 50%
  • Check that the primary DNS is set to the DC’s IP address
  • Check that the secondary DNS is correct
  • Remove WINS from the NIC configuration
  • Run a dcdiag to check the general health of the DC
  • Ensure that the DC is not multi homed.  If NIC teaming is enabled, ensure that it is configured correctly.
  • Run “repadmin” to ensure that the DC is replicating properly and that there are no latency issues

DNS Checks

Mac binding is heavily dependent on a pristine DNS environment.  Duplicate A or PRT records cause major problems.  Additionally, Mac clients prior to 10.7 Lion do not reliably register PTR records.  Without these reverse records Macs can fail to bind and may experience authentication issues.

The first step in any troubleshooting process is to check for duplicate A and PTR records.  Our organization enables PTR record scavenging; this has caused the instance of duplicate PTR records to drop dramatically.  However, duplicates can and do creep in and enabling A record scavenging is not recommended .  A full clean-up involves  removing all workstation A and PTR records and starting fresh.
  • Connect to DNS on the local DC (or open the DNS mmc snap-in)
  • Expand the Reverse Lookup Zones
  • Find the zone or zones for the site
  • Highlight and delete all existing PTR records
  • Do not delete PTR records for non-Windows servers or network devices
  • Expand the Forward Lookup Zones
  • Delete the A records which belong to desktops and notebooks only!
Because of changes in the DNS snap-in, it is no longer possible to easily search for PTR records by subnet.  Therefore in order to find and delete errant PTR entries you must use the DNS services on a 2003 DC or the XP DNS mmc snap-in.

The DHCP server must be set to update A and PTR records as well as grant ownership of the records to a service account.  These changes are detailed in the “DHCP Checks” section of this page.

SPN
Check Service Principle Names (SPN) using setspn -l [server short name]

In particular you are looking to see that the ldap, DNS and HOST entries are present and have both the short and FQDN of the local DC.

SRV
Check for missing or inaccurate SRV records.
  • Open DNS snap-in
  • Go to Forward Lookup Zones
  • Expand the domain
  • Expand “_sites"
  • Locate the site you are working on
  • Expand the location and click on “tcp”
  • Ensure that the correct _kerberos and _ldap entries are present
Most locations should have only one _kerberos and _ldap entry and they should be directed to the local DC.  Some sites have many entries; it has been found that multiple entries can cause slow logins for both PCs and Macs and also prevent Macs from binding/authenticating correctly.  Unless there is a specific requirement, SRV records in this location should be kept to an absolute minimum.

Conversely, if the site is missing _kerberos or _ldap entries they need to be added.  Check the following locations to ensure that the local DC’s SRV records are present:
  • Open DNS snap-in
  • Go to Forward Lookup Zones
  • Expand the domain
  • Click on “_tcp”
  • Check that the local DC has both _kerberos and _ldap entries. If not, add them
  • From the domain level expand “_msdcs”
  • Expand “dc”
  • Open “_tcp” and check that the local DC has both _kerberos and _ldap entries. If not, add them
SRV records for the DC should be created each time Netlogon service starts however, sometimes this must be forced.
  • On the DC open a terminal window
  • Run the command “nltest /dsregdns” to force the DC to register it’s SRV records in DNS
nltest is also useful for checking and repairing secure channel communications issues.  A full list of nltest commands can be found HERE.


DFS
Check that DFS is active on the local DC.
  • Go to Start/Run
  • Type  \\your.domain.here\sysvol
  • Right-click anywhere in the folder window
  • Got to Properties/DFS
  • The active DFS patch should be the local DC
If the local DC is not the active DFS path follow these instructions to correct the problem.

Sites and Services

Like Windows computes, Macs use Sites and Services to ensure that they are authenticating to the correct DC.  Get a list of subnets from the location and ensure that they are entered into Sites and Services correctly.  Make sure the list includes any Wi-Fi subnets that are on the IPG network as well as server subnets.

Double check that the correct DC is setup and that its replication partners are correct.  It is also a good idea to force replication (you may have already done this using “repadmin” in an earlier step).

DHCP Checks

DHCP must be configured in such a way that Mac clients are forced to register A and PTR records when they receive a DHCP lease.

The site must be running a Windows 2003 or later DHCP server in order to make these configuration changes.  The process will not work with Windows 2000 DHCP.
  • Open DHCP manager either through the mmc snap-in or on the DHCP server
  • Right click on the server and select Properties
  • Click on the DNS tab
  • Put a tick in the following boxes
  • Enable DNS dynamic updates according to the settings below:
  • Always dynamically update DNS A and PRT records
  • Discard A and PTR records when lease is deleted
  • Dynamically update DNS A and PTR records for DHCP clients that do not request updates
  • Click on the Advanced tab
  • Click the Credentials button
Here you should enter the name of a service account that will own the DNS records.  You can make the account name anything you like but its purpose should be apparent, "service.dns" or "service.dnsrecords" etc.  Create the account on AD and set the password to never expire.  This account will be used by DNS to add and delete records when machines get new leases or old leases expire.  Without this account records can remain in DNS; if a Mac client attempts to use an IP that is already associated with a DNS record the client can fail to bind.
  • User name: your DNS service account
  • Domain: netbios name for the domain
  • Password: enter the service account password
  • Click OK and OK again to save the changes 
Further DHCP checks
  • Remove WINS from the DHCP scope
  • Check that the DHCP scopes match what is in Sites and Services
  • Check that the FQDN of the domain is correct
  • Check that the primary and secondary DNS servers are correct
  • Look at the DHCP leases and delete any that do not have a resource name associated with them
  • Check that there are enough free IP addresses
User Account Checks
Once a Mac client has been bound to AD it can experience a host of authentication issues.  These normally manifest themselves as a “shaky login”: when a user attempts to log in the authentication window shakes and denies them access. 

Although most of the troubleshooting steps regarding shaky logins involve client-side procedures, there are a couple of things you can check in AD.
  • Remove the UNC path to the user’s home folder in their AD profile
  • Ensure that the SAMAccount name and UPN match and are in all lower-case
Conclusion
DNS issues cause the vast majority of Mac binding and authentication issues.  If a site is having across the board problems in these areas, performing DNS health checks should be Directory Services’ first troubleshooting steps.

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.

Sunday, December 18, 2011

Shaking login with console error: Could not get a user record for [username] from Directory Services

Symptom

After binding a Mac AD account log-ins fail (shaking login).  Console logs report the following:

SecurityAgent[735] Could not get user record for 'username' from Directory ServicesSecurityAgent[735] User infor context values set for usernameSecurityAgent[735] unknown-user (username) login attempt PASSED for auditingSecurityAgent[735] Could not get the user record for 'username' from Directory Services

kinit [username] will generate a Kerberos ticket

id [username] will produce a list of LDAP info for the AD account


login [username] fails


Solution

If you see the Console log errors as described above it generally means that the computer is not able to create a mobile account at log-in.  Try creating a mobile account from Terminal first:


sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/
createmobileaccount -n username
sudo createhomedir -c -u username

Log out and back in with the user's AD credentials.

Friday, October 21, 2011

iOS5: The iPhone ... Could not be synced because the sync session failed to start

iOS5 continues to be a problem.  One of the main complaints is an error encountered when attempting to sync an iPhone or iPod to iTunes:

"The iPhone [device name] Could not be synced because the sync session failed to start"

Several work-arounds have been suggested including simply restarting the iOS device. One procedure that seems to work well is to remove the device backups from iTunes.  Before you do this, make sure you backup your backups folder: ~/Library/Application Support/MobileSync/Backup/
  • Connect your device and open iTunes
  • Go to Preferences/Devices
  • Delete all backups
  • Click "OK"
  • Restart iTunes and attempt another sync
Sometimes you may see duplicate backups listed.  I found that by deleting all but one backup also allows the device to sync.

Apple's iOS troubleshooting page has some good tips:  http://support.apple.com/kb/ts2529



Thursday, October 20, 2011

"You are unable to log in to the user account [account name] at this time.

Problem:  an AD bound Mac shakes off login attempts and returns a message that says:

"You are unable to log in to the user account [account name] at this time.  Logging in to the account failed because an error occurred."

There are two things to to try:

First, update the Automounter master map as outlined in this Apple KB article:

http://support.apple.com/kb/TS3346

Secondly, if the user has a home folder path specified in their AD profile (Profile tab), remove it.