none
PeopleSoft through UAG - Constant Refresh issue

    Question

  • Hello

    I am publishing PeopleSoft through UAG, I have it set up as an 'Other Web application'.  When I log into PeopleSoft, it authenticates and takes me to the landing page, but then the app gets into some kind of refresh loop. It's almost as if someone is sitting there taunting me by hitting F5 constantly. Anyone seen this before and figured out a solution?

    Thanks in advance!
    Tony

    mercredi 29 février 2012 21:21

Réponses

  • Hi Tony,

    This is normally caused by UAG cookie handling that is impacting cookies that are ultimately required by PeopleSoft to function; similar problems exist with other vendors like Citrix. You need to modify how UAG hadles the cookies used by PeopleSoft - this can be quite tricky to figure out if you are new to UAG.

    There is some specific guidance for this scenario in Ben Ari's book here: http://blogs.technet.com/b/ben/archive/2012/02/21/the-uag-customization-book-is-out.aspx

    Alternatively, it may be worth logging a call with Microsoft as this is a relatively common issue I believe...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    mercredi 7 mars 2012 00:02
    Modérateur
  • Sure.  Here is the solution:

    When publishing Peoplesoft through UAG, use the 'Other Web Application' template. Set the application type to be 'PeopleSoft' so it matches the code below (or just make sure application type in line 4 & 16 matches the application type you set up for the application in UAG). Publish as you normally would.

    Create a file called WhlFiltSecureRemote_HTTPS.XML with the following content, and save it in <UAG Path> \von\Conf\Websites\<Your_Trunk_Name>\conf\CustomUpdate\ :

    <WHLFILTSECUREREMOTE ver="2.2">
    <DATA_CHANGE>
    <APPLICATION>
    <APPLICATION_TYPE>PeopleSoft</APPLICATION_TYPE>
    <URL>
    <NAME>.*</NAME>
    <SEARCH>"WHL_DOMAIN_NAME"</SEARCH>
    <REPLACE></REPLACE>
    <SEARCH>'.WHL_DOMAIN_NAME'</SEARCH>
    <REPLACE></REPLACE>
    </URL>
    </APPLICATION>
    </DATA_CHANGE>
    <COOKIES_HANDLING>
    <APPLICATION>
    <APPLICATION_TYPE>PeopleSoft</APPLICATION_TYPE>
    <URL>.*</URL>
    <Set-Cookie>
    <NAME>.*-.*-PORTAL-PSJSESSIONID</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>SignOnDefault</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>ExpirePage</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>PS_LOGINLIST</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>PS_TOKENEXPIRE</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>http%3a%2f%2f.*%3a.*%2fpsp%2fhr88dev1%2femployee%2fhrms%2frefresh</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>PS_TOKEN</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    </APPLICATION>
    </COOKIES_HANDLING>
    </WHLFILTSECUREREMOTE>

    mercredi 7 mars 2012 14:58

Toutes les réponses

  • Hi Tony,

    This is normally caused by UAG cookie handling that is impacting cookies that are ultimately required by PeopleSoft to function; similar problems exist with other vendors like Citrix. You need to modify how UAG hadles the cookies used by PeopleSoft - this can be quite tricky to figure out if you are new to UAG.

    There is some specific guidance for this scenario in Ben Ari's book here: http://blogs.technet.com/b/ben/archive/2012/02/21/the-uag-customization-book-is-out.aspx

    Alternatively, it may be worth logging a call with Microsoft as this is a relatively common issue I believe...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    mercredi 7 mars 2012 00:02
    Modérateur
  • Hi JJ

    You are absolutely right, it is to do with cookie handling.  I was able to resolve this by creating a custom SRA file.  I created this file by looking on an IAG server (which supported PeopleSoft natively). I found the relevant parts in the full SRA file, cut and pasted it into my custom UAG SRA file, and things started working.

    If anyone has a similar propblem, PM me and I'll help you out.

    Thanks
    Tony

    mercredi 7 mars 2012 14:07
  • Hi JJ

    You are absolutely right, it is to do with cookie handling.  I was able to resolve this by creating a custom SRA file.  I created this file by looking on an IAG server (which supported PeopleSoft natively). I found the relevant parts in the full SRA file, cut and pasted it into my custom UAG SRA file, and things started working.

    If anyone has a similar propblem, PM me and I'll help you out.

    Thanks
    Tony

    Lol...I have used the same "look at IAG" approach in the past to solve similar Citrix issues!

    I assume when they removed the old templates from UAG, they also removed the associated SRA elements...

    Be good for the forum if you could post your SRA changes ;)

    Cheers

    JJ 


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk


    mercredi 7 mars 2012 14:09
    Modérateur
  • Sure.  Here is the solution:

    When publishing Peoplesoft through UAG, use the 'Other Web Application' template. Set the application type to be 'PeopleSoft' so it matches the code below (or just make sure application type in line 4 & 16 matches the application type you set up for the application in UAG). Publish as you normally would.

    Create a file called WhlFiltSecureRemote_HTTPS.XML with the following content, and save it in <UAG Path> \von\Conf\Websites\<Your_Trunk_Name>\conf\CustomUpdate\ :

    <WHLFILTSECUREREMOTE ver="2.2">
    <DATA_CHANGE>
    <APPLICATION>
    <APPLICATION_TYPE>PeopleSoft</APPLICATION_TYPE>
    <URL>
    <NAME>.*</NAME>
    <SEARCH>"WHL_DOMAIN_NAME"</SEARCH>
    <REPLACE></REPLACE>
    <SEARCH>'.WHL_DOMAIN_NAME'</SEARCH>
    <REPLACE></REPLACE>
    </URL>
    </APPLICATION>
    </DATA_CHANGE>
    <COOKIES_HANDLING>
    <APPLICATION>
    <APPLICATION_TYPE>PeopleSoft</APPLICATION_TYPE>
    <URL>.*</URL>
    <Set-Cookie>
    <NAME>.*-.*-PORTAL-PSJSESSIONID</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>SignOnDefault</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>ExpirePage</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>PS_LOGINLIST</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>PS_TOKENEXPIRE</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>http%3a%2f%2f.*%3a.*%2fpsp%2fhr88dev1%2femployee%2fhrms%2frefresh</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    <Set-Cookie>
    <NAME>PS_TOKEN</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    <Path remove="true"></Path>
    </Set-Cookie>
    </APPLICATION>
    </COOKIES_HANDLING>
    </WHLFILTSECUREREMOTE>

    mercredi 7 mars 2012 14:58
  • Thanks Tony!

    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    mercredi 7 mars 2012 15:43
    Modérateur
  • Hi Tony...

    I did what you have suggested... yet I continue to get the constant refresh/loop.

    Any other ideas?

    vendredi 13 avril 2012 20:08
  • Umm, I would double check that you have the exact same name (case IS important) in line 4 & 16 as you have in the Application Type when you set up the application (in my code PeopleSoft).

    If you still don't have any luck, I would suggest you try publishing it using the 'Other Web Application (application specific hostname)' template (you will have to create a new host name for the application, and publish it in public DNS, pointing to the external NIC of the UAG). I've had some luck doing this in the past.

    If that also doesn't work then pretty much your only option is to publish it using tunneling, which won't work on phones and ipads and things, but will almost always work on PC's.

    Thanks
    Tony


    • Modifié TKroukamp vendredi 13 avril 2012 20:36
    vendredi 13 avril 2012 20:35
  • I have confirmed that line 4 & 16 are type-specific (PSoft) identical to the application.

    Im curious about this line of code in your previous post:

    <NAME>http%3a%2f%2f.*%3a.*%2fpsp%2fhr88dev1%2femployee%2fhrms%2frefresh</NAME>

    Is "hr88dev1", "employee", "hrms", "refresh" referencing your specific Peoplsoft server app?  do I need to change those in my file to reflect my Peoplesoft link?

    It's the WEIRDEST thing...

    After clicking my PSoft link from the portal ... I log in.... and jump into the hamster wheel of the constant refresh... but then I went and clicked in IE (Tools - Internet Options)... and when that dialog box opened... in the background - Peoplesoft finally logged me in?!

    HUH!?

    vendredi 13 avril 2012 20:46
  • The code is a straight copy and paste from an old IAG server I had access to, I didn't change anything other than lines 4&16.  So nothing else is specific to the environment I used this solution on.

    samedi 14 avril 2012 13:50
  • Jason, Tony,

    Since I've benefited from you guys sharing this I wanted to give something back.

    I've been on site where a customer has many customised pages within their PeopleSoft applications.

    Thanks to this thread we got past the constant refresh issue but found that once people got deeper into the application, application variables were being lost.

    I took a look at fiddler trace from a working client on the LAN. I spotted that the URLs were pretty big, in fact they exceeded the default limits for IIS.

    Adding the following registry key and setting the value appropriately high resolved the issue:

    Location:

    HKLM\System\CurrentControlSet\Services\HTTP\Parameters

    Create a new DWORD value and name it URLSegmentMaxLength

    Ben Ari wrote about this here.

    http://blogs.technet.com/b/ben/archive/2009/03/21/iis-link-parsing-wreaks-havoc-when-ibm-servers-are-involved.aspx

    Thanks again,

    Simon

    lundi 15 octobre 2012 16:06
  • Very interesting, thanks for that!

    Also, Ben Ari just posted this on his blog, which may help some people:

    http://blogs.technet.com/b/ben/archive/2012/10/15/publishing-peoplesoft-with-uag.aspx?Redirected=true

    lundi 15 octobre 2012 21:48