locked
CreateProcessWithLogon in Vista? RRS feed

  • Question

  • I have explored this thread and I don't believe the solution is there:
    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1327209&SiteID=1

    The program we're using is installed using an Admin account, and during the installation process we create our own Admin user in order to install updates.  We use CreateProcessWithLogon to run updates as that user, so that the updates will still work even if the end user does not have an admin windows account.
    Obviously, UAC intercepts this and tells me we need to elevate this.  I've tried going at it using a manifest, but it still prompts the user for an Admin password, which we cannot count on the user having.  Other ways to approach this?

    Thanks in advance for any help you folks can offer.
    Tuesday, September 18, 2007 4:25 PM

All replies

  • I assume that you can't make use of the possible solution in the thread you pointed to because you do not have a service running as SYSTEM to do the work.  Well, someone else pointed out in this forum a year or so ago (I can't find the exact thread) that if your program is running as administrator and elevated, that you can create a service to run as SYSTEM from your program, start that service and have that service do what you need to do and then stop while your program waits, then delete the temporary service that you created.  That is a little extra work, but it can do the job.

    Tuesday, September 18, 2007 7:23 PM
  • Creating an Admin user isn't going to help, as you've noticed it still requires a UAC elevation and, in any case, will break horribly in any environment which uses Restricted Groups to manage Administrator access from within Active Directory.

     

    The single best way of doing this is still to use Windows Installer and configure your MSI package to be capable of Standard User Patching. That way the Windows Installer service can handle all the necessary elevation requirements in a secure fashion. Failing that the next best approach is to set up a scheduled task during installation that periodically checks for updates and handles them as necessary. Creating a full blown service just to handle application updates is probably overkill, as the updater code really doesn't need to run all the time.

     

    Wednesday, September 19, 2007 9:39 AM
  • Interesting thoughts guys, I probably should've clarified why i'm not clear on the above solution.
    "If the user is not an administrator, I create a new local userid with a random password . . . add the user to the "Administrators" group"
    If the user is not an Administrator, how does that account have permissions to create a new user account and add that user to the Admin group?

    Creating another service is an interesting way to go about it, and failing all else we'll probably go that route but i'd had to have to use a whole service just for updates.

    Standard User Patching... do you mind elaborating on this, or pointing me to where I can learn more?  New concept & new idea for me.
    EDIT: ok, I think I understand now.  We're just using a standard exe for our installation, but if we use an MSI installer we can use a sticky elevation to circumvent the UAC prompt?

    Thanks!
    Friday, September 21, 2007 4:33 PM
  •  fb117nighthawk wrote:
    Interesting thoughts guys, I probably should've clarified why i'm not clear on the above solution.
    "If the user is not an administrator, I create a new local userid with a random password . . . add the user to the "Administrators" group"
    If the user is not an Administrator, how does that account have permissions to create a new user account and add that user to the Admin group?

    In the post which you quoted, the code which was examining one user to determine if it was an administrator and if not, creating a new temporary administrator userid, was running in a service as SYSTEM.

     

    I think that when I responded to your post in this thread, I misunderstood whet you needed to do.  I was trying to describe how a task running as an elevated administrator could create a temporary service to do work on its behalf, but I gather that in your case your task is not elevated.  I apologize for the noise I created in this thread.

    Tuesday, September 25, 2007 7:24 PM
  • No problem.  While not a solution, I did learn something in the process so I still appreciate it.

    I think ultimately we're trying to do something that UAC is designed to prevent, because we're trying to do run our updates without an admin present.  Looks like the only path for us to go here is to use a manifest, trigger the prompt and let the end user deal with getting those credentials.
    Tuesday, September 25, 2007 9:02 PM