none
PeopleSoft through UAG - Constant Refresh issue

    질문

  • 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

    2012년 2월 29일 수요일 오후 9:21

답변

  • 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

    2012년 3월 7일 수요일 오전 12:02
    중재자
  • 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>

    2012년 3월 7일 수요일 오후 2:58

모든 응답

  • 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

    2012년 3월 7일 수요일 오전 12:02
    중재자
  • 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

    2012년 3월 7일 수요일 오후 2: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


    2012년 3월 7일 수요일 오후 2:09
    중재자
  • 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>

    2012년 3월 7일 수요일 오후 2:58
  • Thanks Tony!

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

    2012년 3월 7일 수요일 오후 3:43
    중재자
  • Hi Tony...

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

    Any other ideas?

    2012년 4월 13일 금요일 오후 8: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


    • 편집됨 TKroukamp 2012년 4월 13일 금요일 오후 8:36
    2012년 4월 13일 금요일 오후 8: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!?

    2012년 4월 13일 금요일 오후 8: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.

    2012년 4월 14일 토요일 오후 1: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

    2012년 10월 15일 월요일 오후 4: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

    2012년 10월 15일 월요일 오후 9:48