none
After Upgrade to UAG SP3 - XP Clients that update components get "Entry Point Not Found (EventActivityIdControl not located in ADVAPI32.dll)"

    Question

  • We have started experiencing some issues after we upgraded to UAG SP3. The server side install went fine and we tested on some Windows 8 machines without issue But, the below error message constantly pops up on many client PCs (XP SP3) after upgrading to the latest endpoint component version rendering the machines almost useless. Any insight would be greatly appreciated the event log basically says the same error. Uninstalling the components does not resolve the issue.

    "XXXXXX.exe - Entry Point Not Found

    The procedure entry point EventActivityIdControl could not be located in the dynamic link library ADVAPI32.dll"

    <o:p>The ADVAPI.DLL file does not appear to have been upgraded recently as the client I looked at had a time stamp of 2007 for last modification date.</o:p>

    The executable files that cause this error to popup so far are lync, jusched.exe, and momservice.exe4

    Any help out be appreciated.


    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".


    Tuesday, March 05, 2013 2:39 PM

Answers

  • I completed the upgrade to SP3 Rollup 1 last night. The SP3 install went fine (same as last time) but after installing rollup 1 our UAG configuration disappeared. This required a restore of the manual configuration backup I took before installing SP3. Before you can import your backup you first need to upgrade your XML schema version of the backup using the “Configuration Update Utility” located at “C:\Program Files\Microsoft Unified Access Gateway\common\bin\UAGSchemaUpgradeUtil.exe”.


    Then once the backup XML is updated and applied, open the management console and under the “File” menu, click “Refresh Configuration” and the configuration will be available again. I was then able to activate the configuration.

    We are not getting the ADVAPI32.dll error any more on XP clients being updated from previous versions of the endpoint components. So it looks like rollup 1 fixed this issue.


    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".

    • Marked as answer by David Kozera Thursday, April 11, 2013 1:05 PM
    Thursday, April 11, 2013 1:05 PM

All replies

  • Any chance you've found a solution to this?  We are having the same issue with XP SP3 after updating to UAG SP3.

    So far we've seen issues with it on three computers.  Two of them would get that error when opening Outlook (03 and 10) and one when opening IE. 

    Monday, March 11, 2013 9:10 PM
  • Out of curiosity, what version of Exchange are you running?  Also what do you use Outlook Anywhere in your organization? 
    Monday, March 11, 2013 9:26 PM
  • Same here.

    It gives the error on all network applications. It happens even pre-logon. It's system wide.

    Windows XP, SP3. UAG2010SP3.

    Wednesday, March 13, 2013 7:35 AM
  • Exactly the same issue here.

    The hooks that dll provide seem to be used quite frequently across many different applications. We're error-ing out with wScript errors from scripts that apply at startup, Citrix plugins, laptop system software such as the fingerprint reader.. etc

    Basically anything that uses that dll on the system causes an error when it tries to access it.

    All errors started occuring on the UAG endpoint components upgrade on the client PC's when accessing the UAG frontend and rebooting.

    Windows XP SP3

    Endpoint components version: 4.0.3123.10000

    Advapi32.dll version: 5.1.2600.5755

    I've tried sfc /scannow to test dll's on system to no avail.

    Wednesday, March 13, 2013 11:05 AM
  • nmuleski1 we use exchange 2010 SP2 and most of our staff uses web mail. We have not found a solution for this so far. We are working with another Microsoft partner on trying to find the cause. We have rolled back UAG to SP2 until we can find a solution.

    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".

    Wednesday, March 13, 2013 12:25 PM
  • I'm glad to see others are having the same issue at least. I was beginning to thinking the problem might have been unique to our environment.

    We have also not found a client rollback solution that fixes the error as of yet. Has anybody else? We are just re-imaging the effected PCs. Removing the UAG client components does not fix the issue.


    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".

    Wednesday, March 13, 2013 12:31 PM
  • Completely uninstalling the UAG components and then reinstalling them seems to correct the issue for us.  At least it has on the two computers I've had the chance to try it on.

    The big issue here was that just uninstalling the components from "Add/Remove Programs" didn't fully remove the application.  After uninstalling, I had to reboot, go and manually stop/disable the Microsoft Forefront service, then manually delete any remaining DLL files from the Forefront directory under Program Files.  After another reboot I re-installed the components and the issue went away.

    It's also worth noting that this has only happened to end users that use Outlook Anywhere.  That might be coincidence though, since most of our end users that use UAG also use OA.

    Wednesday, March 13, 2013 1:46 PM
  • Nmuleski, I can confirm this has worked for us. Stopping service, uninstalling, rebooting, deleting directory, then connecting to UAG frontend and re-installing endpoint components. (slightly easier than re-imaging- I'd got the desktop team on standby)

    No more errors.

    Clearly some problem with the way the endpoint components are updated on the client if they already exist. Testing from a workstation with no previous UAG component installation there was no issue.

    Thank you for the help.

    Thursday, March 14, 2013 12:34 PM
  • Nmuleski, I can confirm this has worked for us. Stopping service, uninstalling, rebooting, deleting directory, then connecting to UAG frontend and re-installing endpoint components. (slightly easier than re-imaging- I'd got the desktop team on standby)

    No more errors.

    Clearly some problem with the way the endpoint components are updated on the client if they already exist. Testing from a workstation with no previous UAG component installation there was no issue.

    Thank you for the help.

    Good to know.  I've created a batch file that uses the outlined steps to completely uninstall UAG and so far it's worked for all users that have tested it.  I guess we found the issue.

    UAG has always been a PITA for us, at least with regards to Windows XP.  I'll be glad when we don't have anymore XP machines to maintain!

    Thursday, March 14, 2013 2:51 PM
  • We can confirm too that:

    Stopping service, uninstalling, rebooting, deleting directory, then connecting to UAG frontend and re-installing endpoint components. 

    Fixes the error for us too.

    Now we just need a fix for UAG 2010 SP3 server side before we can update again. Does anybody else have an MS support case opened? or can we maybe get an MS response in this thread on the problem?


    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".

    Friday, March 15, 2013 1:52 AM
  • Care to share the script you created? We are seeing the same problem, and no sense in reinventing the wheel.
    Tuesday, March 19, 2013 3:34 PM
  • I can also confirm with the above that doing the steps Stopping service, uninstalling, rebooting, deleting directory, then connecting to UAG frontend and re-installing endpoint components works.

    However a permanent fix from Microsoft would be very helpful in this case. At least gives us insight you are aware of the problem.

    Wednesday, March 20, 2013 4:08 PM
  • I agree that we need a permanent fix/upgrade path. As it stands we are unable to upgrade to SP3 because of this issue.

    I would also not mind having a copy of the previously mentioned script to remove the client and resolve the error.


    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".

    Wednesday, March 20, 2013 4:44 PM
  • Here is a ugly script I put together to resolve this problem for us. It may help.

    NOTE: This was tested with UAG 2010 SP2 Endpoint component.

    Save as a .bat file

    net stop DMService
    net stop uagqecsvc
    net stop whliocsv
    echo off
    pause
    echo At this point the UAG Uninstaller will run. DO NOT RESTART
    rundll32.exe C:\WINDOWS\DOWNLO~1\WhlMgr.dll,UnInstall 3.1.0 63 0 1 4.0.0
    echo off
    pause
    echo Press okay once uninstall is completed to continue.
    RD /s /q C:\Program Files\Microsoft Forefront UAG
    REG DELETE "HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom" /f
    echo off
    pause
    echo Press okay to restart.
    shutdown /r /f

    Monday, April 01, 2013 12:33 PM
  • We are seeing this error on a Windows XP client computer.  We have Forefront UAG installed and multiple applications are reporting the same issue.  

    The procedure entry point EventActivityIdControl could not be located in the dynamic link library ADVAPI32.dll.

    These clients have Microsoft Forefront UAG endpoint components v4.0.0 installed. 

    Check Windows Update, you're probably missing a ton of updates.

    • Proposed as answer by BradleySCS Friday, April 05, 2013 6:59 PM
    Friday, April 05, 2013 6:59 PM
  • Not the case for us.  The issue was completely related to the Endpoint Components not uninstalling properly.

    Friday, April 05, 2013 7:28 PM
  • Okay, I installed all updates on one of them and it didn't fix the problem.  I can't remove Microsoft Forefront UAG endpoint components because they are in use.  What's odd is that other computers are configured just like this one but they don't exhibit this issue.

    Is there a link to an "update" or prior version that I can try?  

    Saturday, April 06, 2013 1:01 AM
  • Hi,

        UAG SP3 Update 1 is available and it contains the following fix......

    http://support.microsoft.com/kb/2831573

    (FIX: Traffic is not forwarded or you receive an error message about ADVAPI32.dll when you use a Windows XP client to start an application from a Forefront Unified Access Gateway 2010 Service Pack 3 portal)

    Might be worth trying.

    Thanks,

    James.

    • Proposed as answer by James Kavanagh Thursday, April 11, 2013 1:13 PM
    Tuesday, April 09, 2013 3:09 PM
  • Here is the direct link to UAG SP3 Rollup 1 for anybody that needs it.

    http://support.microsoft.com/kb/2827350

    We will be deploying and testing tomorrow night. I will provide an update here with the results.


    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".

    Tuesday, April 09, 2013 4:20 PM
  • I completed the upgrade to SP3 Rollup 1 last night. The SP3 install went fine (same as last time) but after installing rollup 1 our UAG configuration disappeared. This required a restore of the manual configuration backup I took before installing SP3. Before you can import your backup you first need to upgrade your XML schema version of the backup using the “Configuration Update Utility” located at “C:\Program Files\Microsoft Unified Access Gateway\common\bin\UAGSchemaUpgradeUtil.exe”.


    Then once the backup XML is updated and applied, open the management console and under the “File” menu, click “Refresh Configuration” and the configuration will be available again. I was then able to activate the configuration.

    We are not getting the ADVAPI32.dll error any more on XP clients being updated from previous versions of the endpoint components. So it looks like rollup 1 fixed this issue.


    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".

    • Marked as answer by David Kozera Thursday, April 11, 2013 1:05 PM
    Thursday, April 11, 2013 1:05 PM