none
PeopleSoft through UAG - Constant Refresh issue RRS feed

  • 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

    Wednesday, February 29, 2012 9:21 PM

Answers

  • 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

    Wednesday, March 7, 2012 12:02 AM
    Moderator
  • 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>

    Wednesday, March 7, 2012 2:58 PM

All replies

  • 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

    Wednesday, March 7, 2012 12:02 AM
    Moderator
  • 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

    Wednesday, March 7, 2012 2:07 PM
  • 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


    Wednesday, March 7, 2012 2:09 PM
    Moderator
  • 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>

    Wednesday, March 7, 2012 2:58 PM
  • Thanks Tony!

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

    Wednesday, March 7, 2012 3:43 PM
    Moderator
  • Hi Tony...

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

    Any other ideas?

    Friday, April 13, 2012 8:08 PM
  • 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


    • Edited by TKroukamp Friday, April 13, 2012 8:36 PM
    Friday, April 13, 2012 8:35 PM
  • 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!?

    Friday, April 13, 2012 8:46 PM
  • 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.

    Saturday, April 14, 2012 1:50 PM
  • 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

    Monday, October 15, 2012 4:06 PM
  • 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

    Monday, October 15, 2012 9:48 PM