Problem with Konica Minolta and Printing with Authentication on Mac OS X 10.10 in an Active Directory Domain Environment

I have a client who has a base of Macintosh OS X users, but they are all joined to the domain for printing and file sharing purposes. They also have apps that requires central authentication as well, as such, a domain environment is required.

The reported problem was simple:

"I am unable to save the Authentication Settings for the username and password for printing color print-out."

Upon inspection, I found out that the issue is that :


I spent 2-hrs over remote to help the user out. I checked the following:

1. ensured key-chain access is removed and not saving any passwords
2. login to different user profiles within the Mac to try, same problem
3. added printer and re-add printer drivers, ensured that printer driver is the latest (5.2.1) for Mac OS-X for Konica Minolta Bizhub C364 (printer in mention)
4. ensured that the LOCK is UNLOCK for all system settings
5. verified that all users that i tried have admin access
6. other printers do not have the same problem. I have 2 printers (one lexmark and the other konica minolta), but lexmark doesn't seem to have problems with saving authentication settings.
7. I read the following sites:
1. http://forumspain.net/thread/konica-minolta-authentication-account-track-greyed-out.html
2. http://forums.macrumors.com/threads/printing-to-konica-minolta-bizhub-c360.1039526/
3. http://manuals.konicaminolta.eu/bizhub-C554-C454-C364-C284-C224/EN/contents/id16-0030.html
4. http://www.copytechnet.com/forums/konica-minolta/87457-authentication-greyed-out-printing-c224e-mac-os-10-9-a-2.html?s=347e833b6c02a4f2594008dbea88a541
5. https://discussions.apple.com/thread/2733341?tstart=0
6. https://forum.openoffice.org/en/forum/viewtopic.php?t=14453&p=67592
7. https://computing.si.umich.edu/confluence/display/SIC/Authentication+-+Mac+OS+X+10.6+and+Before
8. I also re-read the manual for installation... and it's found here: http://manuals.konicaminolta.eu/bizhub-C554e-C454e-C364e-C284e-C224e/EN/contents/id01-_101378675.html
9. I made sure that I tested printing from Chrome, Safari, Ms Word, TextPad and all the issues were the same.  

 Note that in my situation, I have the following scenario:

• this is the only MacBook that was unable to save the authentication details
• everyone on PC and other Mac were able to print.
• the printer is not showing any error, and job logs on the printer admin console shows that print-out are successful.
• my domain environment is a Windows Server 2008r2 domain
• Mac OS-X is 10.10.5 (Yosemite)
• Make sure that it's Authentication and not Tracking that you are troubleshooting. There is a difference and details of the set-up can be found here

The solution:

1. Remove printer driver
2. Unjoin (unbind, that's what mac calls it) the macbook pro from the domain
3. Restart the Mac
4. Re-install printer driver (5.2.1 at this time of writing -  https://www.konicaminolta.com.au/downloads)
5. Ensure that you can save the authentication settings
6. Rejoin (re-bind) to the domain
7. Restart the Mac
8. Test print - it should work now....

Hope it saves you all time instead of having to spend 2-hours like me!!!

Migration from a QNAP NAS to another newer QNAP NAS in a Windows Server 2008 Domain Environment

A client just purchased an upgrade to their existing 5 years old QNAP NAS Storage and they are interested in moving the existing NAS data from the old NAS to the new, and cutting over without (or with very-minimal downtime).

The Old NAS will then be converted to an offsite remote backup storage so that we can keep a copy of all their data in case the building gets burned down.

We will be employing the use of RSYNC and replicating data across WAN, most, probably through a PPTP VPN tunnel. Oh well, PPTP is not very secure, but it is still better than nothing, unless I can encrypt the RSYNC data before transferring it across WAN.

I'll be naming the NAS-es as NAS-1 (current) and NAS-2 (new). I have about 5-TB of data, and both NAS-es are joined to an Active Directory Domain (Windows Server 2008r2).

Overall Plan:

1. Set-up new NAS
2. Transfer data from current NAS to new NAS
3. rename current NAS to a new name (backup)
4. Set new NAS with current NAS name
5. Change DNS settings on server to ensure IP address is set correctly (or change IP of NAS too)
6. Users will then log-in to the new NAS as though they are connecting to the current NAS

Procedure:

1. Set-up new NAS2 in the network (disk, volume, network, name... etc)
2. Join the NAS2 to the same domain as NAS1, verify that the name of the NAS2 appears in Active Directory Users and Computers console
3. Create shared folders with the same name from the current NAS (file shares)
4. Configure Backup - Rsync on NAS1, from NAS1 >> NAS2
1. Ensure that delete extra files on remote destination is ticked.
2. Ensure that ACL is copied over to save time. ( i removed this because it doesn't work well. )
3. I did not configure the delete extra files on remote destination, the result was I had 0.3-TB of extra files on NAS2. Reconfiguration and re-sync took 11-hr for the entire data storage of 3.2-TB.
4. If you miss out option 1, the process of deleting the files that were already removed is quite fast in my case. For 12-GB of data, it took less than 1-min when NAS2 is not busy.
5. Let Rsync run and complete the transfer within the same network from NAS1 >> NAS2 for all of the network shared folders
6. Side project - we want to utilize dual LAN with Trunking for the data access to the NAS2, so we enabled IEEE 802.3ad on port 3 and 4, with a different set of IP address so that we can use that for faster access to the NAS2, while retaining the admin access using the address set in step-1.
7. I then re-configured the Rsync settings with the new IP address that has been configured with the trunk - 192.168.10.4
1. Not a significant difference in replicating speed because the NAS1 output is going through a single gigabit LAN connection.
8. ============== Not yet done ==================
9.  After sync is all completed and when I am ready to cut-over, now I proceed with disabling the Rsync from NAS1 >> NAS2 (to be safe, I'll recommend deleting the jobs)
10. Rename NAS1 to NAS1-BKP
11. Rename NAS2 to NAS1
12. Configure Rsync backup from NAS1 to NAS1-BKP the same steps taken in STEP-4 above.

 
Additional Notes:

• I wanted to test if changing NAS2 (new nas) name after joining to Windows AD will auto configure the name registered in the AD. Unfortunately, although the name change works, the name change did not register at AD.
• Unfortunately, I was required to re-join the NAS2 to the domain because I couldn't set user permissions for the shared folders based on my AD groups.
• I had to re-connect the NAS2 to the domain one more time, and then AD users and computers console displayed the newly renamed NAS2 to the domain. The old NAS2 name is still registered and had to be manually removed.
• then after i have re-joined the NAS to the domain, I proceed with deleting the NAS 2 prev name from the console.
• re-joining to the domain did not affect the network connection and my rSync seems to be working as per norm albeit the transfer time now extends to 2 days instead of the original 12-hours.
• Good news is that previously configured shared folder domain permissions will not be lost when the active directory connection is lost. (However, I did not restart NAS-2 after the change of name-before the rejoining. As such, I am not sure if a restart would possibly cause a shared folder permission reset if the shares are configured with domain permissions.)
• Re-configuring rsync from the NAS2 to NAS1 works flawlessly. There's no re-copying of files, only changed files are copied from NAS to NAS.

Apple Mail and SMTP Offline issues

Client called me this morning, I found out that the apple mail email settings has gone awry. For some weird reasons, my SmarterMail Server settings is shown 'offline' all the time.

I tweaked, re-created account and nothing short of banging the mac on the table... and I realized that Apple Mail on the Mac OS-X (mountain-lion and above) doesn't like non-SSL based SMTP.

Gmail SMTP, or SMTP server that does not uses password authentication works well, but when SMTP authentication is enabled, it seems like a requirement for SSL to be enabled.

As such, since my server utilizes SSL (TLS Authentication) on a separate name for it's server, I had to use our own registered server name - cloudmail.b**.co*.s* and VIOLA! it worked almost immediately.

While it's a nice gesture to make the application smarter and think-ahead for it's users, I do feel that Apple should incorporate some form of warning or alerts into the Apple Mail configuration instead of simply blocking access for unsecured connectivity.

Oh well, time and efforts are already spent... glad that it is all resolved within the hour.