Could do a real quick packet sniff to capture the status codes and content?
I would confirm that the file is being requested, sent, and that it has the
A better question might be if there are any special firewall requirements for the communication between servers? I wonder what port they use? I was trying out the new Coldfusion Server Manager and it lets you add multiple servers with a very similar interface with the only difference being that it works?! Same servers added through the Multiserver Monitor get permission denied? Likewise, no problems when trying the Fusion-Reactor server. I wonder how many people actually use the multi-server monitor?
I probably won't go to the trouble of trying to sniff packets, it's cheaper to buy a third party solution. Thanks for your response Steven.
Since I was actually on the ColdFusion 8.0 engineering team at Adobe and personally tested the multiservermonitor back in 2006/7, I find it very surprising to learn that /crossdomain.xml is now required in the webroot INSTEAD of /CFIDE/multiservermonitor-access-policy.xml.
I did some testing on a couple local ColdFusion 9.01 servers, and to force the requirement of the access file, I loaded the CF Admin Multiserver Monitor over localhost (127.0.0.1) and then tried to add a different CF instance to the monitor using the other interface for the same machine 192.168.1.104. As expected, I got Permission Denied. I then went to the target server that I was trying to add, and I enabled the multiservermonitor-access-policy.xml by uncommenting the appropriate line. I was really stunned to find that the target server still showed a Permission Denied status (Figure 1).
Upon examining the console (Figure 2) where I started the target server, I found a series of error messages for
"error Requested resource '/crossdomain.xml' (%2fcrossdomain.xml) not found",
logged every time the Server Monitor attempted to refresh the view (every 20 seconds).
I went back to the Server Monitor console and switched to the Errors tab (Figure 3) where I found a very helpful message:
"Ensure that you have allowed access to this server by changing the crossdomain.xml file."
With that information in hand, I Googled "multiservermonitor-access-policy.xml" + "crossdomain.xml" and came across the following references:
- A blog comment by Adobe QA Engineer Jayesh Viradiya. "simply Ignore the multiserver-access-policy file and put the following crossdomain.xml file, with appropriate client machine permissions where you are running multiserver Monitor, and put this crossdomain under the CF Server wwwroot, which you are trying to connect to"
- The ColdFusion 9 Documentation on Multiserver Monitor. "Note: The cross domain details need to be mentioned in the crossdomain.xml file and this file must be placed directly under webroot. Previously, this file was placed under <webroot>/CFIDE/multiservermonitor-access-policy.xml. For more information, see www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html "
- ColdFusion bug 79603. "The workaround is: If multiservermonitor-access-policy.xml is renamed as crossdomain.xml and it is placed directly under webroot rather than CFIDE,then it works."
This one went completely under my radar as this is the first time that I found out about this change. When I made the change to my server test, I found it then worked with /crossdomain.xml on the target server.
This should do it for you. Let us know.
Thanks so much for your reply Steven! That explains a lot. I admit I was following an article here:
Which is specific to using the server monitor with CF 8 as opposed to 9. This just happened to be what comes up when I googled for setting up the multi-server monitor and I wouldn't have thought something like this would change between versions.
I will try the crossdomain.xml file later today and suspect it will fix my problems with the version 9 servers. Now my version 8 servers still complain of a Channel.Security.Error, "Ensure that you have allowed access to this server by changing the multiservermonitor-access-policy.xml file." I've got the file edited to allow access from our domain, but now I'm wondering if maybe it's the DNS that isn't properly reporting the full name from one server to the other which would cause this check to fail.
I will continue testing on that front and report back. Thanks again!
A couple thoughts, Brad, first about your observation regarding the article, and then about your ongoing problem with CF 8.
First, on the article, I'm the author and yep, it was written with respect to 8. Not much had changed in 9, so it was not updated. But I have been asked to update it for 9.0.1, since there were monitor-specific changes for that. Look for them in weeks/months to come.
And I will certainly be updating this info about the xml files (in part 4, so will be the last article updated).
Until then, I'll note that anyone can add comments to update them, and I have just now for this, pointing to Steven's blog entry on the matter (http://www.talkingtree.com/blog/index.cfm/2011/1/28/Multiserver-Monitor-Permission-Denied- and-crossdomainxml).
As for your problem on CF8, just note (as I discuss in the article) that it's critical that you get the XML entry just right--www.domain.com is not the same as domain.com (and localhost is not the same as 127.0.0.1), when it comes to configuring that. Hope that helps.
I'll note there could be (at least) one other problem: have you confirmed you can in fact visit the Server Monitor itself? If not, there may be a config problem that would then also preclude the Multiserver Monitor working also. Though it may not be your issue, I'll point out a blog entry I did that addressed one problem:
Thanks Charlie, I understand entirely that the article was written for version 8 and you can't be guaranteed compatibility between versions. I made an assumption this was one of those things that wouldn't have changed between versions.
As for it not working in version 8 for me, it is very strange to me because there is some history in my case. I had an old workstation and on that system, the multi-server monitor worked great. I had a second workstation at the same time, but the multi-server monitor never worked on that PC?? But it worked on the other so I didn't care. (I actually had a post on this topic a couple years ago but nobody ever responded to it). Then when I got rid of my other workstation and moved to a new one, the multi-server monitor never worked again for me. I wish I had that old workstation back just for the multi-server monitor. Anyway, when I look at the errors view in the multiserver monitor, I see an error about ensuring that the multiservermonitor-access-policy.xml has been edited to allow access and mine currently looks like this:
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for ColdFusion Multi Server Monitor access -->
<!-- <allow-access-from domain="*" /> -->
<allow-access-from domain="*" />
I previously tried it allowing domain="*.domain.com" but simply changed it to be wide open domain="*" as the commented example is, restarted coldfusion and still it fails. I can punch in the URL of the flex2gateway and get returned a blank screen (no errors). I can access the server monitor directly on all systems in question, but can't add any to a multiserver monitor running on another server (for example, if I run the multi server monitor on server A and then add server B, I get permission denied. However I can run it on server A and add server A. Likewise, I can run it on server B and add server B but can't add server A.) Incidentally, back when this all worked on my "special" workstation, I could access the multiserver monitor on server C and add servers A,B and C and they all worked.
I've got the same multiservermonitor-access-policy.xml on all my version 8 servers (located in the CFIDE directory). So unless my multiservermonitor-access-policy.xml example is not properly formatted, I can't think of anything else except for maybe some odd firewall requirements for the connections between servers?
Anyway, it's a mystery for sure. I don't know that I care anymore since I've lived without it for so long and now it looks like we are buying fusion-reactor which worked great for us during the trial period.
Let me know if you see I'm missing something basic. It's one of those things I've tried several times over the years and as I said, it all worked from a different workstation (that is to say I successfully ran the web based client from one particular workstation). Thanks again.
Brad, it's indeed easy for this stuff to get confusing. There's precious little docs beyond what I have in those articles.
First, in terms of debugging things, you say you asked for the /flex2gateway URL, but really, you need to be checking for the /CFIDE/multiservermonitor-access-policy.xml URL instead. What do you get back then? Do a view source. Does it show what you think it should show? And to be sure you're not seeing a cached version (cached in your browser). Again, I discuss this in the article. A quick trick (not mentioned there) is to add a random query string to the end of the URL.
Beyond that, and important to your testing, there is something I noted in the article which may be key to your debugging and solving this.
Despite what we may reasonably think, the communication between the multiserver monitor (msmon) and the server being monitored is not between the client where we have the msmon running. Instead, it's between the server being monitored (let's call that server "watched") and that where the msmon itself was loaded from (let's call that Server "watcher").
So when you say you tested calling the gateway url (on "watched"), I assume you tested it from your workstation, but is that where the implementation of CF is installed, from which you launched the msmon ("watcher")? If not, you need to try it from on the box running the "watcher" instance.
There could be some security implementation such that communications from between the "watched" and "watcher" servers does not allow even that simply /flex2gateway url to work. But do try it. I mean, get on the "watcher" box itself and from a browser there, test your calls to the "watched" server.
More important, what happens when you ask (from "watcher" server) for the URL http://["watched"]/CFIDE/multiservermonitor-access-policy.xml?
Note that you may well see that it does not show what you expect, from what you say you know the xml contents to be. How could that be? Well, you may be looking at the xml file on the server in the CFIDE directory that you think (and reasonably assume) is that which serves up the CF Admin for the site you're trying to monitor. But there are all kinds of reasons that can get confused. Sometimes people modify their CFIDE mapping in their web server to point to an alternative location. Sometimes they are pointing at a real location, but the CF server was configured (at install) to point to one in another location (like the \wwwroot\CFIDE). You can look in the CF Admin "mappings" page to see what CF thinks is where its Admin is located. Is that where you were putting this xml file? And is it what you think it should be, in that location?
I'll note as well one could also install CF in such a way as to accept the offer to have the CF admin on a built-in web server, such as via port 8500 (http://[server]:8500/CFIDE/...). In that case, note that that WOULD by default be looking at the \wwwroot\CFIDE, not any in your webroot, so if you launch it that way, you must put the XML file in that appropriate directory. So you may find that when things worked before, you told the msmon to monitor the "watched" server via its built-in web server, or vice versa.
Hope some of that may help. Let us know.
Finally, given this whole thread, is it also possible that there is a /crossdomain.xml file in the site root (again, whatever is the site root for the web site in question) which may be overriding this lower-level file. I don't know enough about these to know for sure, but I do (in the article) point to resources from Adobe with more, as they are a fundamental Flash security feature.
Providing CF and CFBuilder troubleshooting services