slancaster

we just map homedrive at login with no scripts, just the default mac set up at AD bind and then set a MCX redirect to create an alias on the users desktop. works a treat.

Afternoon all, hopefully this will solve a lot of your headaches and answer two common Mac questions. Problem - Desktop wallpaper being centrally managed and dock showing question marks rather than network shares. Remedy: So, the problem with setting your desktop wallpaper on a networked Mac running Yosemite and above is that the network shared is mapped AFTER the preference kicks in to set the wallpaper. To fix this, I created the desktop.jpg and placed it in a network location which all users have read access to. I then created a automator script which takes an input (the full path of the desktop.jpg) and then sets the wallpaper. This script has a 2 second pause at the start to ensure it runs after network connections have occurred. I made a local folder on the client mac named "Scripts", set the rights to everyone read only and put the automator app in there (ensure the automator app has read access for all network users or you may get an access denied icon displaying for other users). Use profile manager to set a "launch at login" item to point at the script. Ensure "desktop lock picture" is OFF to allow the script to set the wallpaper. This flag is set under "restrictions" within Profile manager. Happy days. The second common question is about having network shares on the dock. Again, network shares are connected AFTER the dock settings, so the dock doesn't know where to look and unfortunately doesn't connect to the network shares after clicking the question mark. Same fix really, make an automator app to kill the dock after a 2 second pause. Add script to profile manager the same way as before. screen shots and example automator files attached (note, the paths in the automator script obviously relate to my place of work - just change the paths to match you needs). cheers WallpaperAndDockAps.zip

should this still be a sticky? seems out of date...

Find, or create a small .app file. copy it, paste it, rename it and then put on the dock with profile manager. Prof Man just looks at the name and location. So make a logic.app in the same location as where it will be on the client machines. happy days.

Just found something that has helped... we have been using auto proxy discovery (networksetup -setproxyautodiscovery Ethernet on) which picks up proxy auth on login via kerberos. When the profiles refused to push out to a client, I logged in as a network user and realised that Safari would not load any sites, but Chrome would. Disabling the auto discover (networksetup -setproxyautodiscovery Ethernet off) allowed the profiles to install quickly and without failure. So... my questions are - how are people getting proxy authentication to work?

quite a common problem. Anyone else experiencing this? We have quite random behaviour.. some profiles / settings push nice and quick, others stick and take ages or not at all. Latest server version apparently addresses similar issues, but I've not seen an improvement.

CISCO set up here, I don't believe it has a bonjour gateway feature but i'd have to check...

enable auto discover on the mac client machine and then check your web filter is set up correctly. Kerberos should do the rest. Profile manager is a royal pain... terminal on / off command here networksetup -setproxyautodiscovery Ethernet on

if your AD is set up a certain way, you can go to the local admin account on the client mac and go to system preferences/users/login/ then "edit" on network account servers and open directory utility. Then go to your AD bind, and tick the use UNC box. DONT click force local home though or this will confuse things. does that help? oh and the code for username is %short_name%

Got about 30 ATVs on site. The "reliable" ones seem to be the ones used daily. The others are hit and miss, its almost like they go to sleep and don't "wake" correctly (even though sleep is set to off)

we have lots of discovery / connectivity issues with our ATVs within a school environment. Fingers crossed for a fix, and a central way of managing / updating the ATVs would be great too...

Afternoon all, Profile manager is driving me nuts. Basically I'm moving from a 10.9 and Workgroup Manager server environment to a 10.9 client and 10.10 server running profile manager. I have a set of test machines which point at the new mac server running profile manager - I'm not crossing the streams with any current / old systems. I will re-image the estate once (if ever) profile manager is sturdy. My main question is, are there any techies out there who have a successful Profile Manager environment within an education establishment? We have an AD domain and use OD to piggy back on to it. Basically the Mac server just sets user accounts and machine settings - no network files as such are stored on the mac server. Workgroup manager worked a treat and I'm quite comfortable with editing custom plists. Profile manager however just seems to clunky with failed profile installs here and there. Things that I've not got solid yet on the Profile Manager set up are : - desktop wallpaper set from a central network location - sidebar favourites intermittent - exchange settings intermittent (setting server location and username etc) - plus I'm sure lots more that will become apparent

im struggling to get a centralised wallpaper set using Profile Manager. worked fine for WGM. Something to do with drives being mapped AFTER the settings for Wallpaper are loaded - did you at least get a successful network stored wallpaper file to load correctly?

no problemo! The local account tick box can be handy for 1:1 Mac books to act a bit like a roaming profile, but we just map network shares or auto map home drives on login for domain users.

From my understanding, if "force local home directory" is ticked, this means any files saved to this area will only be saved locally to that Mac, so when they move machine, their files will not move with them. This is a problem if personal user areas are mapped on login.

Thanks for the reply Wolverine, in our establishment however ticking the local home directory box would cause more issues as we mount network homes at login. Currently we are using SMB 1, 10.9.5 clients and a Windows AD and things seem ok with acceptable speeds. I'd like to enable SMB 2 / 3 but I'm a bit scared of the Library folders going crazy again!

yeah we had to take a performance hit to fix the corrupt files bug. Do we know if SMB2 / 3 is ok now on 10.9 and 10.10 machines?

Force SMB 1 on mac clients and it seems ok. We had this problem with 10.9 and Samba 2 - permissions went mental! From Macworld.com --- There's also a possibility to change all connections to use SMB1 system-wide (for all users) by entering this command in Terminal: sudo sh -c "echo '[default]' >> /etc/nsmb.conf; echo 'smb_neg=smb1_only' >> /etc/nsmb.conf" To restore the default SMB2 you simply need to delete the newly created configuration file (nsmb.conf) with the command: sudo rm /etc/nsmb.conf ---

we use Smoothwall and for transparent stuff it seems fine. Proper authenticaion / user tracking is tricker on a iPad though.

haha no probs! Sounds like we are im similar boats. Im in the process of migrating from Workgroup Manager to Profile Manger so I may be on here looking for, and posting more fixes.

Certificate Install to System Keychain - Smoothwall SSL *export guardian cert.crt from smoothwall* first copy your guardian cert (.crt) to the root drive of each mac with ard then use this command from ard which adds the file to the local SYSTEM keychain (run as root) replace “certname” with the name of your cert. certtool i /CERTNAME.crt k=/Library/Keychains/System.keychain At this point the cert is installed, but not trusted on your test mac. Login locally to the mac (you only have to do this on the “test” mac) open Keychain, find the certificate in system certs and “trust all” for the cert. You now need to make a copy of the local trust settings file. This file is located /Library/Security/Trust Settings/Admin.plist Put this file somewhere easy to access for yourself. Copy this file to each mac with ard inheriting permissions to the same location, reboot all mac's and trust settings are now applied. You should now have 1 mac with the trusted certificate on. Now to batch this process across multiple macs you need to do the first step of copying the cert locally, then run the terminal command to add the certificate and then copy the Admin.plist file to the SAME DIRECTORY on any mac you wish to use this cert with. I use apple remote desktop to send the files and run the scripts. Takes no time whatsoever once your files are prepped. One extra step which helps speed things up in a school environment (and also allows youtube iFrames to pull through on google sites etc) is to go in to smoothwall and set the HTTPS Interception warning frequency to “never” rather than weekly etc. For the future however, we are going to install this certificate on the base image for our Macs or at least add the script to the end of our deploy studio workflow. Hope that helps and makes sense!

Bump! exact same query here. For now we have used ARD to push out the smooth wall cert, then a terminal command to add cert to system keychain (not user) and then pushed out a .plist to "always trust" the cert, and then disabled the nag screen box in smooth wall for HTTPs inspection. Ideal option is to have the cert on my mac server tho but ive had no joy, even tried re-exporting the certificate as pks12 but no joy

"unable to login at this time" can sometimes relate to your AFP/SMB network settings. If set incorrectly, you canne login. Go to directory utility and check to see if "network protocol to use" is set correctly, under the active directory tab (if your DC is on a windows box)

no problem on the iPhones / iPads / iPod Touches Assuming you have the latest iOS you need to click on "settings" "wifi" and then join your desired wifi network. After joining the network you click on the blue disclosure triangle, next to the wireless name. This opens up the advanced settings page. At the bottom of this page there is a "http proxy" section. Click "Auto" and then type in the location of your .pac file in our case its http://172.16.80.2/pac/pacfilename.pac

Here is the text from our .pac file stored on our Xserve. All of our portable devices point to this pac file and we have no problems. function FindProxyForURL(url, host) { //Loopback and localhost always goes via browser direct. //include any local bypass domains here as well, in the format "shExpMatch(url, "************.local*") " if ((host== "localhost") || shExpMatch(host, "*localhost.*") || shExpMatch(host, "*172.16.80.2*") || //our xserve shExpMatch(host, "*172.16.80.1*") || //our DC shExpMatch(host, "*172.16.80.67*") || shExpMatch(host, "*172.16.80.52*") || shExpMatch(host, "*169.254/16*") || shExpMatch(host, "*xserve.mmhs.school*") || shExpMatch(host, "*mossmail.mmhs.school*") || shExpMatch(host, "*172.16.80.3*") || //our mail server shExpMatch(host, "*172.16.80.59*") || shExpMatch(host, "*172.16.80.109*") || isPlainHostName(host) || (host == "127.0.0.1")) { return "DIRECT"; } //All other requests go through port 8881 of wc***cal.***********.local // should that fail to respond, go directly to the WWW: return "PROXY 10.112.5.193:80" //our external proxy }