Gerk

Wrong forum .... http://www.edugeek.net/forums/mac/94524-please-do-not-post-about-apple-mobile-devices-mac-forum.html

It's important to know that you delete the content of that folder, but not the entire folder. If you delete the folder then Finder will create a dummy file on login and you will see the issue you've been having there. Try making an empty folder at /System/Library/User Template/english.lproj/Library/Keychains if you don't already have one on the machines.

As long as the newer/older hardware can both run the same versions of Mountain Lion you should be fine on that front. For AD I think the answer is "it depends"... worst case you may have to re-bind the OSX server, I think it depends on how restrictive your AD setup is (i.e. if it's setup to only allow bind from specific hardware/MAC addresses).

Yep that sounds about right, I wasn't paying that close of attention to be honest ... but I think that may also be the second board he bought. He also still ended up having to swap out to a different CPU as well, but finally got a stable combination as far as I know. It all just reminds me of the old days doing linux when there was really limited hardware support, etc. I prefer using computers to building them these days

Just to be clear, it's likely asking you for the admin username and password for the remote server at that point (the one you're trying to administer) and not a local admin username and password. If that doesn't work try your local one, maybe it needs to update a file or local permission to allow it to run as expected. If neither of those work I dunno, works fine for me

Hackintoshes pretty much only lead to the path of pain. Even if it "worked out of the box" .. that only applies to _this time_ ... I just watched a buddy end up spending about a solid month and well over the price of a new Mac in order to build a Hackintosh. He ordered the mboard from a company that specializes in hackintosh stuff that was supposed to "just work". So two motherboards, two complete sets of ram and two different processors and he _almost_ has it running properly. And about a month of debugging and fighting and reading and waiting for customer support replies that never came. If you want to run OSX ... but a Mac. If you just like to tinker because you can ... run Linux and knock yourself out. On the other hand if you like having a machine that may or may not end up running as expected, will be incredibly fragile, and will have you quaking in your boots every time you see the word update, then Hackintosh is the machine for you

Clone the whole OS install with SuperDuper or Carbon Copy Cloner would be my best recommendation. Migration Assistant has a bad habit of not working as expected.

First there was no such thing as a G5 Mac laptop, at least not one that made it to release. Second that's not the reason why Apple started buying up semiconductor companies, they bought them up so that they could manufacture their own ARM based silicon and save themselves a lot of money. It had nothing to do with the whole PowerPC/Intel transition and it had nothing to do with keeping up with the Joneses so-to-speak, it had everything to do with their bottom line. They already had people designing the processors at that point in time, they just needed to be able to build them without being at the mercy of another company for the costing portion of things. Lastly @seawolf, do you really assume that because something is made in the US it has better quality control??? That's so ridiculous it's not even funny. If so then the brainwashing has been successful. I can tell you first hand that built in US doesn't necessarily mean quality ... take a look at the auto industry! I'll give you that one as you seem to be pretty far away from the US, but as a Canadian and living right next door I can certainly tell you different no matter how many people in the US try to defend that position.

Oh and _never_ trust time machine. I've seen it fail so many times it's ridiculous ... even when it looks like it's working you can sometimes end up not being able to actually get your data back out of it when you need to. Go figure, a bad hack using all kinds of hard links on an unsupported filesystem. What could possibly go wrong?

Carbon Copy Cloner (which is basically just a front-end for rsync with some added bells and whistles) can do this. It's not free any longer but it's inexpensive. You can pick exactly which dirs to backup and the location to back them up at and schedule backups.

On SMB shares it's probably trying to make the .AppleDouble hidden file (which may be why it's asking for admin permissions). You might want to check that the users have permission to make hidden files on that share (if there's such a thing on the windows user/ACL management, I'm not sure)

All of those file types you're talking about (mov, mp3) contain additional metadata that needs to be written in a different way to SMB shares than it's stored on a local HFS filesystem. That said not sure how to fix this ... but it might be a starting point for you to dig in further.

Funny enough it hasn't happened in our labs for a while now (and I didn't change any configurations). I'm thinking that it might be a networking thing, if there's a hiccup at the wrong time maybe it pauses the queues and then starts the chaos ...

If you're not using something to manage the computers (Workgroup Manager, Profiles, third party software, etc) then you'll likely have to modify the default User Template on all of the machines to already have the details for Office pre-copied into them. You should google this one as it can get pretty involved and there's a lot of good tutorials out there on how to do this. If you do have management software running all the machines then you should be able to override the preferences for Office (again a google will help here).

ARD saves the usernames and passwords for each machine in the local account (i.e. in your case your admin account is setup to know the remote machine usernames and passwords but their accounts are likely not). It's probably asking for the username/account on the remote computer (not the local one). If their home folders stay after logout (ours do not) then ARD should "remember" the usernames and passwords when they next try to use them. As for accounts to allow ARD access you can set this in the clients themselves (and even restrict access to what they are allowed to do). This is done in System Preferences->Sharing->Remote Management. You can then set which local accounts can access the machine and what type of things they are allowed to do. By default it only allows admin accounts, so this is likely what you are seeing here.

In WGM there's a spot to specify login items, it might work better than trying to add it as you did. I think it's Preferences->Login->Items. Also make sure that there is a copy of the app on all the local machines (login items want to run from a specific local path). In my case I put them all into a subfolder in /Users/Shared on each of my lab machines. I did something similar but I did it with a straight Applescript app (to mount student shares) and it worked out ok for me. Lastly a suggestion, try using the command "whoami" instead of looking to the console. I've seen some strange things happen with console in the past. whoami should always return the shortname of the currently logged in user (and if it doesn't it might give you some extra info for debugging). Hope this helps.

You're probably better off asking this sort of stuff in a forum dedicated to network setup, this doesn't really have much of anything to do with Macs (and this is the Mac forum).

Well as I say it happens with our Lexmarks as well. Not sure what they might have in common except that maybe they both have crappy drivers :/

It all depends on your network.

The pausing is a per machine thing. If the printer runs into any issues it will pause and if the users are not admin users you can't seem to resume things. I've had the same exact issue in my labs with both a Xerox Phaser and a couple of different Lexmark printers. In all those cases I just have to ARD in or go the machine locally and resume the queue. I don't think this is a Xerox specific thing, I think this is a Mountain Lion issue personally ...

Hmm nope shouldn't be anything else you have to do, that's an odd one. Are you somehow locking down the printer options in WGM and maybe that's why they are not showing up when you're adding them manually? Other than that I have no idea what is going on there, sorry.

I should mention that I didn't even attempt to use it for any mobile devices, for me I was testing it for lab computers only.

Haven't done it but I suspect it's also not allowed, but you'll have to read the EULA to be sure.

Only thing I can suggest is to make sure you have the very latest version of the driver stuff and that you might have to also copy it to the client machines if they don't get pulled from the server automatically. It really sounds like you have some old software there to me.

As a workaround you could add the printers to all the machines with ARD using lpadmin via the command line (make sure to send the command as "root" if using ARD). lpadmin(8) - cups.org