AntonioRocco

Hi Michael Yes! I'd never use .local to form the basis of internal DNS services in an all Macintosh environment. In theory DNS itself does not 'care' what you use. The only 'requirement' is it must look like a valid .TLD. Using dot earth, dot here, dot now, dot private etc is actually fine and you're only limited by your imagination and the exclusion of .local of course! If it was me I'd use the institution's real world domain and configure the internal view to reflect the external one. IMHO it's simpler in the long run. If you did try to use .local (I've tried many times) you'd have all sorts of problems sooner rather than later. Even if you managed to get Apple's equivalent of Active Directory (Open Directory) to start it would not work well. Bits of it would work (sort of) and other bits won't. Eventually the whole LDAP structure would implode and become practically unusable. FWIW I've been to many all mac sites experiencing multiple issues that were using .local and once removed . . . "it just worked" (sic). I should clarify the advice I gave in the previous post:- On itself you can use either the server's IP address, fqdn, bonjour name or loopback address. For connections to the Server App, Server Admin (depending on OS version), WorkGroup Manager and DeployStudio (if installed) and wherever possible I always try to use the fqdn. Across the network and wherever possible, it's fqdn. HTH? Antonio Rocco (ACSA)

Hi @Michael I don't think the problem OP is experiencing has anything to do with the .local domain problem? Most domains will consist of at least two parts. The namespace e.g.: someplace and the domain suffix (or .TLD) earth. The third component of any domain will be the server's name offering a dedicated service. Using someplace again as the example that would be www. Putting the three together would give you the server's fully qualified domain name (or FQDN) http://www.someplace.earth. If all we're talking about is DNS then osxserver.local would not be a domain. What is often little understood about the platform is its multicast nature. When connecting any mac (including mac servers) to any network, they will announce and discover themselves (similar to the way NetBIOS does on the PCs) using Bonjour/Rendezvous. Bonjour is a zero-config protocol that makes it easy for non-IT savyy users to quickly setup any network using a switch and a few ethernet cables without the need or knowledge of a Server, Router, DHCP, DNS or anything else. The .local suffix was reserved for that purpose and all macs 'know' themselves firstly by their bonjour names. They can't fully resolve .local names as there would be nothing on the network that will translate those names to IP addresses and its reverse. Why is it then that macs have a problem with domains based around .local? In theory they shouldn't. In reality they can and often do. It all depends on how many namespaces you're using. If you're using a single namespace e.g.: someschool.local then don't be surprised if you see some random and intermittent problems. They can be made to disappear by properly configuring the DNS Service and massaging a setting on the workstations prior to binding to the domain. A double namespace e.g.: someschool.someauthority.local never gives a problem in my experience. A mac server will 'know' itself by it's bonjour name - osxserver.local, its FQDN - osxserver.someschool.com, its loopback address - 127.0.0.1 and its network IP address - 10.10.10.10. You should only use the server's bonjour name and loopback address on itself. Clearly you can't use the loopback address across the network and my advice is to use its bonjour name only on itself. @ajames Your problem may have nothing to do with the servermgrd daemon? It may be a keychain problem? Have you applied an update or reset the password recently or some time ago? HTH? Antonio Rocco (ACSA)

Hi ". . . Apple probably added a check into iPhoto '11 due to receiving complaints from users who found iPhoto didn't work over network protocols . . ." I can't say for certain but I don't believe this is true. As already pointed out earlier in the thread, iPhoto (as it exists now) has a monolithic slab of a database that contains images. If one image is modified or changed the whole of the database is written across the network. This can cause major problems if multiple users with large iPhoto libraries are doing this regularly. This was not the case in earlier versions. This assumes you want or need to use iPhoto. Ultimately you do have a choice. You can choose not to use it and simply store images in the Pictures folder in a similar way to the My Pictures folder on Windows. There are plenty of free/paid for apps you can use to view and/or edit these images. You could consider the Apple's other offering, Aperture. iPhoto can be made to work in a network environment by simply redirecting the Pictures folder to a temporary location (a cache) on the local drive for a user login session only. The cache is then flushed on successful log out. I've a feeling you may be able to achieve this using a GPO redirection policy. The share containing user homes exists on the DC after all. It's worth a try don't you think? One of the many reasons why OS X Server (you do know you can install OS X Server on any qualifying mac hardware don't you?) is useful in a mac integrated AD environment, is because you can apply a platform compatible redirection policy using the built-in MCX redirector found in /System/Library/CoreServices. Remember OS X Server costs approx £20. For that amount it's worth not having the hassle of yet another trip into GPMC. HTH? Antonio Rocco (ACSA)

Hi System Requirements for iLife 11 (assuming installer Media - i.e: a DVD) is 10.6.3, Intel Processor, at least 1GB RAM and at least 5GB of free disk space. Individual components of iLife require additional system requirements. For example Garage Band's "Learn to Play" needs an Intel Core 2 Duo Processor or better. 24-bit recording in Garage Band requires a 24-bit audio interface compatible with OS X. AVCHD in iMovie also requires an Intel Core 2 Duo Processor or better. If you're planning to purchase the suite of Apps from the App Store (requires 10.6.6 or later and an Apple ID) the same advice applies. As with any PC a fairly general 'rule-of-thumb' is to install as much RAM you can afford and that the hardware can support; a fast-ish (7200rpm 3.5" or 5400rpm or faster 2.5" - - SSD would be best), large-ish capacity (250GB or larger) hard drive and the latest OS the hardware can support. If iLife is installed from the Media you update it using Software Update from the Apple Menu/System Preferences. If purchased from the App Store the updates will come from the App Store itself. You can't manually download an update .dmg for an iLife component installed from the installer media and expect to apply it to the one purchased and installed from the App Store. The same is true the other way round. HTH? Antonio Rocco (ACSA)

Hi It only disables the More Gestures part of the Trackpad Preferences Pane. Point & Click, Scroll & Zoom are unaffected as is the Trackpad Preferences Pane as a whole. I've tried this on a number of Macs and it works as described. You should not have to restart either as the effects of the commands are immediate. Maybe there's something else going on or a deeper underlying issue? HTH? Antonio Rocco 9ACSA)

Hi You can 'fine-tune' access to the Trackpad options with these commands: chmod 700 /System/Library/PreferencePanes/Trackpad.prefPane/Contents/Resources/moregestures.xml chmod 700 /System/Library/PreferencePanes/Trackpad.prefPane/Contents/Resources/pointclickgestures.xml chmod 700 /System/Library/PreferencePanes/Trackpad.prefPane/Contents/Resources/scrollzoomgestures.xml The result of any of these commands will be to completely disable (hide) the options in the Trackpad Preferences Pane. HTH? Antonio Rocco (ACSA)

Hi There's a number of ways you can do this. If you have ARD handy you can send this terminal command: chmod 700 /Applications/Mission\ Control.app/ Send the command as root. Now whenever anyone (including the local admin account) clicks on the App in the Dock nothing will happen. To reverse the command use: chmod 755 /Applications/Mission\ Control.app/ Another way (again using ARD) is to simply move the application from the top level Applications folder to the local administrator's Desktop. Use this terminal command: mv /Applications/Mission\ Control.app/ /Users/localadmin/Desktop/ Again send the command as root. Now when anyone but the local administrator clicks on the Icon in the Dock nothing will happen. Users will simply see a ghostly question mark. To reverse the command simply reverse the paths. You could also use whichever Apple specific deployment tools you have to either apply a retrospective workflow or build an image that has the application removed, disabled or locked away. HTH? Antonio Rocco (ACSA)

Hi If you've bound client workstatons to Active Directory then accessing mapped networked drives/shares with that option enabled will work. This is a good example of SSO in action. If that share has a common user name and password and users are logging into client workstations using their own AD Credentials then it won't work as they'll be prompted for the other account credentials every time. This appears to be what's happening based on your description of the problem. If users all logged in with that account name and password then it would work but at the same time you would have other (potentially major) issues. It would be simpler if you defined access to that common share by adding appropriate AD Group or Groups users logging into mac workstations are part of. There are three golden rules you need to remember about the mac platform regardless of whether you're going to integrate or not. In no particular order these are DNS, DNS and . . . DNS. Get this bit right and everything else will follow and try and avoid the use of .local as the TLD for your private domain. The errors you're describing do sound DNS related in some way? Key things to remember: 1 Make sure you've created appropriate DNS Records for your Mac Server - A and PTR entries are all you need. If your Windows Server is handling DNS then it makes sense to use it. 2 Make sure the Mac Server has a reserved and fixed IP Address. This can be assigned using a static map via DHCP if you wish 3 Make sure your DHCP Service is pushing out to client workstations appropriate DNS Server IP Addresses and Search Domain information to successfully resolve hostnames with 3 Profile Manager won't work well if at all unless the Server is promoted to OD Master Role. You use the Server App to promote to OD Master (not Server Admin) and you use Server Admin (not Server App) to demote. 4 Profile Manager won't work if there internet reachability is an issue. In other words try and avoid access to the internet is via an authenticated proxy 5 Profile Manager must user port 443 internally The above is not a definitive or exhaustive list by any means but should help you in some way? Antonio Rocco (ACSA)

Hi Although old this link should still apply in general? http://www.edugeek.net/forums/mac/5796-mapping-windows-network-drive-login.html Basically: 1 Install OS X Server's Server Administration tools on any mac client when logged in as a local administrator. 2 Once installed, launch WorkGroup Manager and connect to the LDAP node. Your Mac Server must be configured as an OD Master for this to work and you use the Directory Administrator (diradmin) account that was created on promotion. You may not see the LDAP node initially but simply clicking on the small blue globe and selecting "Other . . ." and then navigating to LDAPv3 and selecting the presented loopback address will get you there. 3 How you apply the setting is up to you but applying it at Group Level is what I usually do. Simply create an OD Group and then add (nest) AD Users and or Groups into that Group. Prior to promotion your OS X Server should be joined to the AD Domain. That way when you try and add desired AD Users and Groups you'll be able to 'see' them. 4 Click on the Go menu and select Connect to Server. Key in the path to a desired share. For example: smb://nameorIPaddressofyourserver/pathtoshare. When prompted use the administrator name and password for that server to mount the share. 5 In WorkGroup Manager, select your Group and click on the Preferences Icon. 6 Click on the Login icon. 7 Click on the Items tab and drag into the window the previously mounted share. You can add as many shares as you like. 8 Make sure you tick the "Authenticate selected share point with user's login name and password" option. 9 Do this for as many groups you've created. For example you may have an OD Students Group that has your AD Students group nested within as well as a similar one for Teachers. Some things you need to consider:- 1 Depending on the OS X Version of your server and client you must make sure you install the correct version of the Server Administration Tools 2 Don't use Staff or staff as these are reserved for the OS itself. Be a little more imaginative when creating groups on OS X. Use Teaching Staff instead or something even simpler such as Teachers or Tutors. If you've created a folder previously (for sharing purposes) on OS X Server that has the same name as the group, then you won't be able to create the group. Create the group first followed by the folder/share. 3 Most mac-style GPOs are best applied/configured on the Client rather than the Server. Mapping networked drives on the Server will never work. Strange you're having problems with Profile Manager as it would be ideal to set this policy as it's web-based and can be ran anywhere. If you've been trying to do this on the Server then it won't work as already mentioned. There may be other reasons why Profile Manager did not work but I would eliminate this one first. Profile Manager should only be used for applying Profiles to IOS Devices and mac workstations that are 10.7 or newer. For older OS (10.6, 10.5) use WorkGroup Manager instead. For a mixed OS environment (10.7, 10.6, 10.5) use WorkGroup Manager instead. HTH? Antonio Rocco (ACSA)

Hi Mark (HodgeHi) is correct. Prior to 10.4, ACLs were not supported and only 10.4 Server can assign overriding ACLs to file shares using a recognisable GUI. Command line only for the Client OS. For 10.3 or older standard POSIX (UNIX) permissions only. The POSIX permissions model is limited when compared to ACLs. You can't have multiple owners or groups and there are only 4 possible permissions variations - read/write, read only, write only and no access. This does not necessarily stop you from using 10.3 as a file sharing server but you will run into permissions problems very soon! By default any user becomes the owner of any file or folder they create. Any one else who is not the creator will have read only access. Furthermore these default permissions 'follows' files or folders regardless of where they are stored. You can work around these default permissions but it can become an administrative nightmare very quickly as well as being a PITA. POSIX permissions are assigned by default and is by design. Amongst other things this is what POSIX compliancy means. Apple takes this aspect of their OS very seriously. If the hardware you're using is at least a G4 867Mhz Processor or better (best if a G5 processor) and meets the recommended requirements, you should still be able to source 10.5 Leopard? Possibly Amazon and/or eBay? Doubtful for 10.4 Server although you won't know until you try? Antonio Rocco (ACSA)

Hi It's not recommended but I think you can configure AD's Password Policy to not require a Password. Have a closer look at the Server's Security Policies. One way or another an answer should be there? HTH? Antonio Rocco (ACSA)

Hi Just a thought but why don't you dispense with the RM Login script? If I've understood you correctly and if it's the same Login script that RM have used since CC2 you probably won't need it? Simply bind the client workstation to Active Directory. User's home folders will map correctly provided you're using the UNC path option to define its location. Just because it's RM it does not mean AD is not there somewhere. Granted it's buried below a mess of contradicting scripts but it's still there nevertheless. Apart from the latest Mac Air and MacMinis you can 'downgrade' iMac 21.5" and 27" models to 10.6.8 as Mark has already pointed out. Your only problem is there is no Universal installer for 10.6 beyond 10.6.3 which won't install on those model iMacs. You must start with 10.6.8 as a minimum. HTH? Antonio Rocco (ACSA)

@jd20075 Hi "is there away using ARD to change all mac to reflect the new time server without having to do them one at a time?" Yes. Launch ARD and select the client workstations. Click on the UNIX Icon. Click on the Template option - top right hand corner of the interface. From the pull down menu select System Setup and from the sub-menu select Network Time Server. It should present this command in the window: systemsetup -setnetworktimeserver time.apple.com Replace time.apple.com with the IP address of your NTP Server. Explore the further options available via the Template pull down menu as you will find most of them useful. The systemsetup and networksetup command line binaries are extremely useful utilities and only a very few are available in ARD. To see the full options available for both utilities launch Terminal on any mac (client or server) and consult the manual pages for both: man systemsetup man networksetup You can test a desired command on a single workstation first and copy/paste from the Terminal window into the ARD Send Unix Command window. Send the command as the 'root' User otherwise it won't work. @chazzy2501 There are very little WPAD options supported in the OSX Interface. You can configure further WPAD options for OSX Server's DHCP Service beyond what's available in the interface by editing /etc/bootpd.plist. There are other sites but this one pretty much lists what is possible: Adding DHCP Options in Mac OS X Server | Krypted.com HTH? Antonio Rocco (ACSA)

Hi It makes no real sense to 'hide' Users' individual Library folders as it allows for easier troubleshooting either for the users themselves or administrators. Especially true when addressing common issues such as corrupted/damaged plists in their Preferences folder and/or caches in the Caches folder. Individual users can be instructed to do this themselves or, alternatively, an administrator can do this for them using a Terminal command on the Server itself or via ARD. With the release of Lion Apple decided to 'hide' the Library folder. It's fairly trivial to access this again without having to resort to the command line or anything else. Holding down the 'alt' key whilst clicking on the Go Menu will 'reveal' it again. Once 'revealed' it can be dropped into the sidebar for easier subsequent access. That way there's no need to hold down the 'alt' key again. You could take this a step further and load an appropriately amended com.apple.sidebars.plist into the MCX Manifest section in WorkGroup Manager. That way everyone nested within an OD Group gets that setting. This assumes you're managing users via OD Groups? HTH? Antonio Rocco (ACSA)

Hi Give these people a call: Western Computer - Home They know their stuff and they're not far from Bristol City Centre. Not certain if they have CRB Clearance? Some ASEs don't in my experience. Think of it this way mate, it will only cost you a telephone call to find out. HTH? Antonio Rocco (ACSA)

Hi It depends on what you mean by restricting access? You can't deny any user at least read only access to Applications installed on that workstation. If you did the user would not be able to launch any applications stored in /Applications. You should be aware that any user logging into any Mac other than the local administrator, or any other user (network or otherwise) that has been made an administrator using a non-obvious, non-gui method, has read only access to the internal drive anyway. Or do you mean you want to deny them the view of the internal drive completely? If this is what you want simply apply the Simple Finder MCX in WorkGroup Manager. Ultimately you may find this to restrictive? You could apply a Finder MCX to not display the drive but you'd have to amend the Sidebars property list as well. You may also want to think about disabling the Go to Folder option in the Go menu as well. You could use ARD to send a terminal command hiding the drive completely: sudo setfile -a V /Volumes/Nameofthedrive The above won't work for 10.7. You should be aware that any of these commands will hide the drive for everyone including the local administrator. You'd have to use the Go to Folder option in the Go Menu if you wanted to access the hard drive as the local adminstrator and sometimes there is a need to do this. What will work for all systems is: sudo chflags hidden /Nameofthedrive Which I think will be your best option? You can revert back to the default with: sudo chflags nohidden /NameoftheDrive You can drag/drop the internal drive into a terminal window to see the full path. Enter the path into the UNIX Section in ARD preceded by the command above. If it was me I would not do this as it's purely cosmetic and as already mentioned, any user other than the local administrator can't do any real damage to the OS or anything else stored on that drive. If your question is really about denying access to Applications in the Utilities folder there are (IMO) better ways to do this. HTH? Antonio Rocco (ACSA)

Hi It's probably simply a typo but you have an extra space between the first double quotes and the word Media. Apart from that your question might get more attention if you posted here: https://discussions.apple.com/community/mac_os/mac_os_x_technologies?view=discussions#/?tagSet=1044 Apple maintain other dedicated forums in addition to the AppleScript one. This one is for Unix: https://discussions.apple.com/community/mac_os/mac_os_x_technologies?view=discussions#/?tagSet=1048 HTH? Antonio Rocco (ACSA)

Hi There has been very little from Apple regarding this since its release. What little there is is here: http://manuals.info.apple.com/en_US/lion_server_upgrading_migrating.pdf and: https://help.apple.com/advancedserveradmin/mac/10.7/ You could sign up for an approved Training Course but these can be expensive. As far as I know there are none for Lion as of yet apart from what's available on the ASTO (Apple Sales Training Online) Portal. Historically the manuals are of little specific use as most are extremely generalised and some just plain wrong. However and only if you're prepared to wade through thousands of pages, there is enough there to to get you going. Basically you're on your own as a lot of the skill set you're going to need you should be bringing to the table yourself. An appreciation and some working knowledge of the Command Line is a must. Some Scripting would not go amiss - Bash, AppleScript, Perl, Ruby etc. An understanding of basic networking concepts such as TCP/IP CIDR, Routing etc and most important of all DNS. It cannot be stressed enough how important DNS is to the general well-being and robustness of OS X Server. And that's before you consider anything else. One final important tip - avoid the use of .local. If you can and FWIW, use split-DNS as ultimately it's easier in the long run. HTH? Antonio Rocco (ACSA)

Hi The XServe need not be involved as it makes no sense to install Apple Remote Desktop on it as you'd have to VNC to it to use it. What would be the point unless you have a display, keyboard and mouse attached to it? Enable Remote Management on every mac you have. You can't do this remotely. You will have to visit each mac in turn to enable the setting. You'll find it in the Sharing Preferences Pane. Make sure you enable all the options. Install Apple Remote Desktop on any one of these Macs that you decide to use as an 'administrator' mac. Make sure the local administrator's name and password is the same for all 300 workstations. Switch on all 300 workstations. ARD does not traverse subnets easily so you will have to add the macs to your List from the Scanner part of ARD by searching each of your subnets, or the subnet the macs are likely to be in. Once you 'see' them all, select them and click the Observe icon. Provide the local administrator's name and password. Do this for all the workstations. Once added select them all and click on the UNIX Icon. Click on the Template popup menu and select Network Setup > Web Proxy. Read what's presented carefully and for the "networkservice" part of the command amend it to either be Ethernet or Airport depending on how your clients are connected to your network. For the domain make it the Proxy Server's IP Address. The last part of the command should be fairly obvious. Make sure the command is ran as "root". The command may fail if some of your clients are on a Wireless network whose VLAN/subnet is far removed from the wired one. Apple make available (for free download) many Administration Manuals on their website. The one for Apple Remote Desktop is here: Apple - Support - Manuals The one I think you may want is here: http://manuals.info.apple.com/en_US/ARD3.2_AdminGuide.pdf It's for ARD Version 3.2 but don't worry as it will still be applicable for the version you have. HTH? Antonio Rocco (ACSA)

Hi ". . . just wanted to know what having them both the same does, so i know what went wrong, just for my own curiosity" Just like PCs, Macs appear (when bound to AD) in the default Computers OU. You can move them afterwards if you want to or (better still) create a Mac specific OU and specify it in the path when binding. They are then authenticated using that computer account only. Users logging into Mac workstations will then be authorised using their accounts as they exist in AD. Using the same computer name for both platforms means you will see authentication issues depending which platform you were on when first logging in. If you logged in on the mac platform you won't be able to log in on the Windows platform. This is because (as far as AD is concerned) that workstation has already been authenticated (it only has the one unique name remember) and won't allow any further authentication until the Principal Ticket has expired. You can use command line tools (on both the mac and PC side) to destroy and renew tickets at any time as a temporary fix if you wish? Kerberos tickets (unless you change the default settings) generally last 10 hours. HTH? Antonio Rocco (ACSA)

Hi There are a number of command line tools (binaries) you canuse. Log in as the local administrator on that workstation, launch Terminal and issue the "last" command. It will show login, logout times and duration of login session etc. Issuing "ac -p" will show the history of who logged in and how long they were logged for as a total. You could also check out the "uptime" command. Consult the manual page for usage "man uptime". Issue all the commands without the quotes. HTH? Antonio Rocco (ACSA)

Hi A number of ways you could do this: Disable NetBIOS over TCP/IP and that should stop the Macs 'seeing' PCs in the Finder SideBar. This assumes you're not supporting any older applications that you may be running in Virtualisation/Emulation on one of your Windows Servers? If everything you have is XP or better there's no compelling reason AFAIK to leave the option enabled. However you will have to double-check with the network designer/administrator first. If that person happens to be you and you absolutely know everything you need to know regarding your network then you're the best person able to answer the question. Put all the Macs in their VLAN/subnet. Macs are by design Multicast first and Unicast second. The Finder and Finder Sidebar supports Bonjour and NetBIOS Browsing by default. Bonjour does not traverse subnets easily so placing all the macs in a different subnet should stop them 'seeing' other nodes that are in different subnets. This IMO is an easy 'fix'. Restrict what users see in the sidebar by applying an appropriate MCX. There are other ways I can think of but any one of or a combination of the above should do. HTH? Antonio Rocco (ACSA)

Hi Actually you don't need ARD, ChickenoftheVNC, JollyFastVNC or anything else. VNC Server and Client is built into every Mac (Client or Server OS). All you have to do is enable Remote Management in the Sharing Preferences Pane and enable all the options. Remote Management is enabled by default (as is SSH) on every Server OS install. You have to manually enable it on the Client OS. Once enabled there are a number of ways to remotely connect to it. From any Client Mac simply click on the Go Menu and select Connect to Server. Key in the IP Address of the Mac Server preceded by vnc:// and at the prompt provide the Server's administrator name and password. Another way is to launch the Screen Sharing App which you'll find in /System/Library/CoreServices. Drop it into the Dock for easier access. Yet another way is to launch any browser and in the url field key in vnc://ipaddressoftheserver. Once you've connected to the Mac Server you can enable further features in the Remote Management option in the Sharing Preferences Pane that will allow you to VNC from a PC. Click on the Computer Settings button and enable the "VNC Viewers may control screen with password" selection. Key in a password that is not the same as the local administrator's password. Download and install any one of these three VNC Viewers for Windows - RealVNC, TightVNC or UltraVNC. If it's RealVNC make sure you select the highest display colour option before connecting to the Server. There may be others you can use but the three I mention do work reliably. HTH? Antonio Rocco (ACSA)

@ SC92 Administrator accounts in my experience will have elevated privileges not normally assigned to standard or student users. What logging in as an administrator does though is it gives you the possibility of troubleshooting the issue as a permissions or access one? I should add that not all RM CC Deployments are the same in my experience. Some of them are quite good and don't display the issues you're seeing. Others are like yours and sometimes worse. Clearly there's a difference somewhere? Which is what the other contributor (bossman) to your post is alluding to. I think you're going to have to get RM involved in some way if you want an effective and long lasting solution? HTH? Antonio Rocco (ACSA)

Hi Looks like you've eliminated those potential issues! Just for a giggle disconnect the network cables and see if the problem goes away. I recently (last week in fact) did 42 iMacs - same OS for Mac and PC as yourself - and saw the problem on two of the 27" iMacs briefly for about 2-3 seconds. This was a music suite only recently 'professionally' re-cabled. Turns out the Sparkies did the cabling. Disconnecting them from the network, swopping the new switch for another new switch, followed by a reboot 'cured' the problem - or at least it appeared to. I use the Deployment Tools Apple provide rather than something like DeployStudio. I have heard from a colleague who has seen similar problems. His solution was to build another image which did not have BootPicker installed. He used ARD to install and configure it afterwards. Problem went away. You have to bear in mind BootPicker is showing its age now. It's 32-bit and has not changed since Mike Bombich first made it available. He appears to have dropped support for it - AFAIK - 3-4 years ago. Perhaps you should consider rEFIt instead? HTH? Antonio Rocco (ACSA)