I can confirm the problem. It was reported as a bug during the seed period and it was claimed that a solution was under investigation, but apparently Apple decided it was more important to get a version out that would work with Lion even though there were still problems. We'll probably just have to hope for an update in the near future.
Hi Dave, thanks for the reply and confirmation of the bug - its just as I suspected.
I really wish that Apple would pay more attention to Apple Remote Desktop, we have been running version 3 for a number of years and all they seem to do is push out updates for compatibility with new versions of Mac OS X and they are normally quite buggy. Any chance of ARD 4 with new features? Multiple install at the same time rather than queuing?!
Looking forward to this particular bug being squashed asap.
ARD is most definitely a low-priority project at Apple. I believe, though I can't say with certainty, that it has been at best a part-time assignment for a single software developer at Apple (I'm going based on replies and comments received from bug reports I've submitted), so developments move at a rather glacial pace, and there's no strong emphasis even on stamping out all the bugs in existing versions, much less pushing hard on new versions. Whether there will ever be a full new version I have no idea, though I would not be surprised at any point were Apple to drop ARD as a product. We'll just have to wait and see.
Meanwhile, anyone looking for a truly enterprise-quality management solution would be best advised to look to other developers, IMHO. ARD is at best an inexpensive "if it works, it's handy, but we don't depend on it" sort of solution.
Sorry to seem a wet blanket, but unfortunately ARD has never been a particularly robust solution. Now that it's much less expensive from the Mac App Store, it's not without merit or use (the old price for the unlimited-client version made ARD with all it's faults a much more difficult proposition to recommmend) and is useful for things like computer lab management and other limited situations, but I don't think any organization with a large number of Macs to support can really depend on it.
As I said above, it's clearly a low-priority product at Apple and gets just enough attention so that it's not completely nonfunctional, but never really gets the sort of development needed for an enterprise-class tool. Anyone looking for an enterprise-class management solution for their Macs would be better advised to be looking at LANDesk, JAMF's Casper Suite, or other such tools.
While I appreciate your response, it is thoroughly unhelpful to the people like myself who are having this problem. It almost sounds like you're a salesman for other products. I know that's not the case (considering how many "points" you have). However, I'm under the impression that ARD does get updates, and even if a single developer is working on the product, that doesn't change the fact that apple advertises the ability to Generate Reports.
If Apple advertises the ability, then I don't suggest anyone give up on the issue by throwing up your hands, as you suggest.
Let me first say that I've been using ARD to generate reports for ~40 computers without problems for quite a long time. It has become an integral part of my workflow.
Anyway, enough of me taking out my frustration on you, here is what I've tried (to no avail... yet. I'm going to solve this if it kills me or I have to reformat my computer) :
1. Repairing permissions on the clients and the server using diskutilty. This would have been a solution since I could have rolled it out via the command line. But no dice.
2. Uninstalling & reinstalling ARD admin (http://support.apple.com/kb/HT2577). I'm unable to fully install , however, since my user list is automatically repopulated.
3. Restarting the service on clients using kickstart (http://support.apple.com/kb/HT2370). This changes nothing.
I've checked the console, and I did (before removing ARD via KBHT2577) get the error "Encryption key not found for client." I no longer get that error. I've got clients on 10.6, 10.5, and 10.4. So I've tried generating reports for each to see if it affects only certain versions. When connecting to 10.5 and below, I get the error "legacy packet not allowed 111 from 127.0.0.1."
The weird thing is that prior to uninstalling the ARD Admin program, clients were hanging on "transferring report" and I was seeing "Encryption key not found for client." in the console.
Now, after reinstalling, clients are hanging on "generating report." There is no error in the console.
Just giving my input of what I've tried, and what I'm seeing. Sorry if I came off as rude to you, Dave.
Okay, I feel as if I've made a little progress. I've used the terminal to kill both ARDAgent and any associated processes on the client. I've then gone back to my ARD Admin utility on my server and closed that.
Then, I started the ARDAgent on the client via the command line (as root), and I've started ARD Admin on the server via the command line (also as root).
I then choose to "generate report" and it still hangs on "transferring report." But in the console/terminal, I see several enteries of:
sysinfocachegen GetSpecificTrashSizes: /.Trashes not found
So I sshd into the client, and checked to see if /.Trashes exists. It does. Thinking it was a permissions problem, I chmoded /.Trashes to 777 (everyone can read, write, execute). I then reran the command to generate reports, and I get the same error. So I deleted the folder and recreated it. No dice, with same error.
It is my opinion, that this might be the root of the problem. It sounds like sysinfocachegen can't generate reports because it hangs on /.Trashes not found. At the very least, I think it's related.
As a starting point, I've tried running sysinfocachegen from the command line on my localhost (and on one of my clients).
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support/sys infocachegen -p -a ~/Desktop/com.uprusc1.systeminfo.plist
Checking the console, the same error comes up:
7/26/11 4:03:27 PM sysinfocachegen GetSpecificTrashSizes: /.Trashes not found
I've tried googling that problem, and I can't find anything at all. Does anyone have any thoughts? I'm pretty sure ard uses sysinfocachegen to generate reports. If sysinfocachegen is hanging, then that would explain our problem.
You did indeed come off as very rude. I can only attribute it to frustration, which I understand but don't appreciate being taken out on me, or a failure to read everything I posted, or both.
All of the solutions you mention were tried during the 3.5 seed and none cured the problem. As I said, the seed manager for ARD confirmed this as a bug and stated the engineering was working on the problem. Apple chose to release 3.5 anyway, with the bug uncorrected. If someone can come up with a workaround for this problem, I'd be very happy to see one, but so far no one, not even Apple Engineering, has come up with one.
As to my statement of my opinion, I've been a seed tester for ARD since before the first release, so I'm very, very familiar with the level of emphasis and the resources Apple puts into the product, and I stand by my statements. ARD certainly can be useful and I don't wish to rule it out completely as a tool that should be in any system adminstrator's toolkit, but in my opinion (one based on years of working with Apple in regards to ARD) ARD should not be relied on as an enterprise-class tool. You are of course free to disagree with me if you wish.
As to the specific problem of reports failing with the endless "transferring", thus far there appears to be nothing we users can do to fix the problem on our end and will have to wait for a fix from Apple. I'd be over the moon if someone could come up with a fix we users could implement (short of reverting back to 10.6.x) but none appear to be forthcoming. If you wish to consider that "giving up", that's fine with me.
And no, I'm not a salesman for any of the other products (nor for Apple, either). I'm just some schmo whose been doing this for a lot of years.
This is incredibly depressing... if that's the case. I guess I should offer to make you a deal, considering I've already gone through denial and frustration/anger.
Its frustrating to me that I couldn't have looked into those bug reports and saved myself some time (as you said that everything I've done has already been tried...).
Does this bug affect everyone? If so, would you suggest everyone who uses ARD file a bug report? I've read that bug report duplicates sent to Apple raise the priority (since you can only view bugs you've sent in yourself).
In the mean time, I'm trying to hack together a script to at least retreive the systeminfo.plist, that I can send out via ssh and have the client place on an ftp server.
Whether it affects everyone running ARD on Lion I don't know, but I'm not the only one who has reported the problem, and as I said Apple confirmed the issue. You can if you wish submit the bug via Apple's feedback page:
You can also register as a developer and submit a bug via their bug reporter, but such registration is not free.
Whether either would raise the priority within Apple I don't know.
I've filed a bug report via your link, via https://bugreport.apple.com, and I've also joined the ARD mailing list.
I'd like to note that I don't have any Lion clients, nor is my admin machine running Lion. Just like the original poster of this question, I'm running 10.6.8, and I'm connecting to various clients from 10.4-10.6.