none
500 Internal Server Error, Your computer does not meet the security policy requirements of this site.

    Question

  • Hi,

    I have a problem with my UAG portal.

    In front of our UAG server we have a TMG array.

    External users who connect to the portal have 5 out of 10 times the following messages

    "500 Internal Server Error"

    "Your device does not meet access policy requirements for this site"

    "Your computer does not meet the security policy requirements of this site. For more information, contact your administrator."

    After closing the Internet Explorer window and opening a fresh one, than they will be able to log on to the portal.

    When I take a look in the UAG web monitor at the security events, I see the following.

    A request from source IP address 172.16.1.200, user to trunk portal; Secure=1 for application Portal of type Portal failed. The endpoint device does not comply with access policy settings (Hybrid_Default_Session_Access) for session 10C3AC33-55F1-4B20-9B70-8CCE39316CC6. The URL is /SecurePortalPortalHomePage/.


    A request from source IP address 172.16.1.202, user to trunk portal; Secure=1 for application Portal of type Portal failed. The endpoint device does not comply with access policy settings (Hybrid_Default_Session_Access) for session 382A858B-A1E6-48CC-96AF-234361B24BC1. The URL is /SecurePortalPortalHomePage/.


    The ip'adresses 172.16.1.200 and 172.16.1.202 are those of the TMG array, the UAG has 2 nic's one for the DMZ 172.16.1.100 and one for the Production network.

    Can anyone help me with this problem, I tried nearly anything possible, all the changes I did to the UAG made no difference.

    The TMG Array has a HTTPS listener and a Forward for the public IP to the 172.16.1.100 (UAG Portal)

    It look as if half of the time UAG decides to not trust the devices behind 172.16.1.200 and 172.16.1.202.

    Does anyone know of a solution?

    Tuesday, November 08, 2011 1:32 PM

All replies

  • Hi Aumatics,

    Do you get the same if you disable one of the TMG on your array (i.e have the client access via single TMG server)?

    What if you access the portal from one of the TMG machine itself (i.e. open browser on the TMG) ?

     

    Ophir.

    Wednesday, November 09, 2011 1:14 PM
  • Hi Ophir.

     

    From recent tests I can tell it had the same troubles as from any client.

    For the sake of it I did try it just now, I receive the followiing messages

     

    "You cannot access this site due to an internal error" "Try to access this site again in a few minutes"

    I press F5 and than I receive a "500 - Internal Server Error"

    Press F5 again and I get the "You cannot access this site due to an internal error" "Try to access this site again in a few minutes"

    Pressing F5 doesn't change anything now anymore, the "You cannot access this site due to an internal error" "Try to access this site again in a few minutes" wil stay there..

     

    Untill I close this Internet Explorer windows and open a new IE window I have the Portal logon screen.

     

    This behaviour is on both the TMG machines, and is the same for clients trying to access the Portal.

    Both the TMG's have the UAG endpoint client installed, this doesn't make a difference, the error is the same with or without the endpoint client installed on the TMG, I put it there for testing purpose.

     

    Hope you have any idea what this could be.


    • Edited by Aumatics Wednesday, November 09, 2011 1:39 PM
    Wednesday, November 09, 2011 1:38 PM
  • This sound really bad :-(

    Here is what I suggest:

     

    1. Try IISReset on the UAG machine and test again.

    2. If you still get those errors, check the OS event viewer for any suspect events (mainly if IIS related or IIS crahes, etc).

     

    Ophir.

    Wednesday, November 09, 2011 1:41 PM
  • Did I tell you that this behaviour is with a completely fresh installation of UAG.

    I just did a compltete rebuild of the UAG machine last week and all I did at first was create a portal and one RDP application.

    Same troubles.

     

    IIS reset, completely reboot, no go.

    Event logs on the UAG show no indication of errors.


    • Edited by Aumatics Wednesday, November 09, 2011 1:46 PM
    Wednesday, November 09, 2011 1:45 PM
  • At this point, here is what I can suggest:

     

    1. Try to disable the client components installation:

        Advance trunk configuration --> "Session" tab --> check "Disable component installation and activation"

     

    2. Try to access the portal from the UAG itself (to elimanate all the other network) by launching the browser on the UAG after you create HOSTS entry on the UAG pointing the public hostname to the external UAG address.

     

    If at this point you still gets those errors, my recommendation is to open a support case, as this require some trace analysis and the public forun is not a good place to do that.

     

    Ophir.

     

    Wednesday, November 09, 2011 1:53 PM
  • Ophir,

     

    But what will happen when I disable "Disable component installation and activation"

    Will new users and PC that connect for the first time still be able to use the UAG portal.

     

    Tried the host file trick and can tell that when I use the external public IP wich will pass thru the TMG's I will have the same errors.

    Change the portal address to the internal IP wich is on the outside of the UAG machine than the troubles are gone.

     

    So safe to say that TMG is the spoiler.

    Wednesday, November 09, 2011 2:02 PM
  • Hi,

    The "Disable component installation" will prevent UAG from installing/using the client compoentns. This is just as a troubleshooting method to see if issue related to the client components/detection phase or not.

     

    When I said "External Address" I mean the external interface on the UAG (the DMZ address) which is not the TMG but should be the local address of the UAG. If that what you mean by "Internal address" then we are on the same page here.

    So indeed this sound related to the TMG. Do you see any events in the TMG log if you run live query when access from a client via the TMG? Maybe the TMG block some packets and the UAG does not get all requests from the client ?

    Since there is already TMG on the UAG, what is the reason you are using another TMG outside ?

    Ophir.

    Wednesday, November 09, 2011 2:24 PM
  • Ophir.

     

    I will try to disable the client components toight, but I guess it won't make a difference because the 500-internal error tht also pops-up from time to time is there in a split second when it does happen.  But I will give it a try.

     

    When I said "External Address" I mean the external interface on the UAG (the DMZ address) which is not the TMG but should be the local address of the UAG. If that what you mean by "Internal address" then we are on the same page here.

    That's what I meant indeed. same page here.

     

    I just tried something new, I added the 172.16.1.101 address in the host file on the TMG's, this host file is empty as it should be. Standard when I ping my portal address from of the TMG they would respond with the public address, well that shouldn't be a biggy because in the Publishing rule there is an entry pointing to the 172.16.1.101, but I have little to loose so I give thius a try and see if it helps..

     

    The UAG itself allready has the 172.16.1.101 address pointing to itself in the HOST file.

    I wait a few minutes and see if the error comes back. I'll let you know.

    Wednesday, November 09, 2011 2:33 PM
  • Hi,

     

    The disable client components test is not relevant anymore (as we found the issue is TMG and not the client components). So don't bother test it.

     

    I still recommend to check the TMG live logging to see if it drop any request, but I think you are in the good direction.

     

    Ophir.

    Wednesday, November 09, 2011 2:37 PM
  • Ophir.

     

    The problem is solved.

    I added 172.16.1.101 in the host file on the TMG's so instead of resolving the public ip of the portal it would now only look for the portal on the dmz side.

     

    So it turns out to be a TMG issue, strange, we host a variety of Sharepoint sites and all kinds of websites and this is a first one to misbehave this way.

    Still, we did receive three warnings today that the portal was unreachable for more than 10 seconds, and a second after we received a message telling us the portal recovered.

     

    So still some issues I suppose.

     

    Thanks for the help.

    Thursday, November 10, 2011 3:23 PM