Windows IT Pro published my second Server Performance Advisor article in the January issue, and I received several emails from people who ran into problems configuring remote data collection. My first response was (of course) "Well, it works on my machine". I am a software developer after all :)
I wrote those articles back in September and October, so I had resurrect my SPA lab set up. I built two VM images using R2... the first was a DC called SPADC1 and the other was a member server called SPAS1. Both were members of the spa.local domain. I installed SPA v2 on both, and configured SPA in the Data role on SPADC1 and the Report role on SPAS1. I then created a share for the C:\PerfLogs\Transfer directory on SPAS1, and granted Everyone control access to the share.
You can configure the data collectors to use whatever credentials you want, but by default they run under the LocalSystem account, and this is how I left the collector on SPADC1 configured. When a LocalSystem process accesses a networked resource, it presents the credentials of the machine account it is running on, so I gave SPADC1$ control access to the Transfer folder as well.
And when I ran the collector on SPADC1, the data never showed up on SPAS1! WTF? This had worked before.
I first checked the Application event log on SPADC1, and the problem was clear: "Access to the path \\SPAS1\Transfer\System Overview" was denied. So SPA running on SPADC1 was able to create the "System Overview" subdirectory, but could not access it. Odd indeed.
Looking at the DACL on the System Overview folder showed that SPADC1$ did NOT have access to the System Overview folder, even though I had granted that access on the Transfer folder. The "Allow inheritable permissions" flag was not set on the System Overview directory and the permissions did not inherit down to the System Overview directory from the Transfer folder. So apparently when SPA on SPADC1 created the folder, it did not set the inherit flag. I set the inherit flag on the System Overview directory and reran the data collector on SPADC1, and got the same error, this time on the \\SPAS1\\Transfer\System Overview\Current directory. So I set the inherit flag there as well, and reran the data collector on SPADC1. And this time it worked.
Doing this for every machine and every collector would be a big PITA, not to mention a maintenance headache. A better strategy is to create a group and add all of the data collector machine accounts (assuming you use the default LocalSystem account on the data collectors) to the group, and grant access to the Transfer folder structure to the group. The only problem with this is that when the data collectors create the subdirectories under the Transfer directory, they don't set the "allow inheritence" flag, so permissions you set on Transfer will not flow down to the subdirectories. So you still have to edit the DACLs by hand for this to work.
However, SPA does insert two groups into the DACL for the folders it creates... it grants read priveleges to the the Report server's Performance Log Monitors builtin group, and read/write privelges to the Performance Log Users group. Note that these are local groups on the Report server, not domain groups. But you can add the machine accounts of the Data servers to the Performance Log Users group, and they will then have the necessary writes to create and use the subdirectories in the Transfer folder.
I don't recall running into this back in October, and I suspect that it has something to do with the fact that the server I configured for the Report role had at one point been also configured for the Both role. Or perhaps I had messed with the ACLs at one point or another and didn't note it in the article. In any case, when you configure a SPA server to act in the Report role, be sure to add all of the Data collector servers to the Report server's Performance Log Users group. That way the Data servers can properly create the folder structure SPA requires.