password change RRS feed


All replies

  • Hi Ruud,

    This issue is similar to what discussed here: http://social.technet.microsoft.com/Forums/ar/forefrontedgeiag/thread/f31a493f-a36a-4f91-8239-baf6ccc062b2

    In your case, try the following (different file this time):

    1. Locate the file LoginChangePassword.asp in the …\von\InternalSite\ folder

    2. Make a backup copy of this file, in case you need to revert to it.

    3. Open the LoginChangePassword.asp file for editing, and search for the word “action”. You should find action=”ValidateChangePassword.asp”

    4. Change this to: action=”/InternalSite/ValidateChangePassword.asp”

    5. Save the file and test.

    Note that, if you have an array of UAG servers, you will need to perform this change on each UAG server, as this change will not replicate automatically across the array. This issue is also planned to be fixed in the upcoming UAG rollup.

    Tuesday, January 10, 2012 10:00 AM
  • Hi,

    I know about this modification. And already applied it succesfully in the past. But the error is now "The URL contains an invalid parameter". Not the url cannot be found, which can be resolved by changing the asp file.


    Best regards

    Tuesday, January 10, 2012 10:09 AM
  • Hi Ruud,


    Can you confirm you made the change on the LoginChangePassword.asp (as instruct below) in addition to the LoginContinue.asp file (that was mention in the other thread) ? 



    Tuesday, January 10, 2012 10:12 AM
  • Hi,

    Thanks. I was in the understanding the url was referring to the validatechangepassword change.

    It works again now.

    What i do not understand is why it worked before with the validatechangepassword change, and then suddenly the functionality stopped working and I have to change antoher file. Could it have been a microsoft update?

    Thanks again.


    Ruud Boersma

    Tuesday, January 10, 2012 10:30 AM
  • Hi Ruud,


    The two files are for two different scenarios. One related to the challenge-response pages and one for the password change.

    Hope this clarify.



    Tuesday, January 10, 2012 10:41 AM
  • It's clear,

    However after the change it worked, but after reativating the portal (for a new published app), the problem is back:

    You have attempted to access a restricted URL.
    The URL contains an invalid parameter

    This is the url: https://hostname.domain.nl/InternalSite/InternalError.asp?site_name=werk&secure=1&error_code=20&policy_id=

    The changes are still in both files.

    Tuesday, January 17, 2012 1:57 PM
  • Hi Ruud,


    This issue now resolved in the latest UAG rollup: http://support.microsoft.com/kb/2655012


    Can you test with the rollip1 and see if this fix your issue ?



    Wednesday, January 18, 2012 3:55 PM
  • hi Ophir,

    I have installed sp1, rollup1 for sp1 and the update 1  for rollup 1. Also installed tmg sp2 and updated the whole machine.

    After updates, the password change worked fine.

    But after a week of production the problem is back:

    You have attempted to access a restricted URL.
    The URL contains an invalid parameter.

    This is the url:


    Tuesday, February 28, 2012 2:59 PM
  • Hi,

    I will put this post up again, because the problem is still nog fixed. I have build number 4.0.1773.10110 installed now for a while, but users are still complaining.

    Do i need to revert the manual change I did to logincontinue and valicatechangepassword. Because those files seems to be untouched by the updates.

    best regards,



    Thursday, March 22, 2012 11:25 AM
  • Hi Ruud,

    What is the date you see on those files (LoginContinue.asp and LoginChangePassword.asp)?

    The correct date if you are using build 4.0.1773.10110 should be 12/12/2011. If you have a different date, it mean the hotfix did not update your files.

    If you need, I can send you the files from my machine, just email me directly offline (my email is the same as my tag name with the (at) microsoft.com).



    Thursday, March 22, 2012 11:46 AM
  • Closing the loop here, Ruud other issue was not related to the original problem.

    It seems users authenticate using UPN and this together with the long domain name cause some users to hit the limit of the 50 chars in InternalSite_Rule9. Increasing the limit size to higher number solved the issue.

    Monday, March 26, 2012 3:43 PM