WinAppxD validates client users using the domain name found by running LookupAccountSID() against the NT account used to start up WinAppxD. Typically, this means that any client users running "appx -c" must be defined in the same domain in which the APPX server participates, because when WinAppxD is defined as a service, it starts up in the domain the server is assigned to.

This means that if your APPX server running WinAppxD is a member of your UsefulApps domain, that users which are defined ONLY in your CorpUsers domain will not be able to login to APPX. If we looked on the client to see which domain the client user was logged into and sent that info to the server, it would work, but today (as of 3.3) we do not do that. You are restricted to validating logins only in the same domain your APPX server belongs to.

DESPERATE to get around this? If you don't use your server for much else besides APPX, and it's in a secure room or you don't mind running a locked screensaver all day, you might be able to do it. Just walk up to the APPX server machine and login to your master domain, or useraccounts domain, or whichever domain your user accounts are found in. Make sure you are using an account in the Administrator group, and which has the four magic user rights set (as documented elsewhere in the FAQ). Now start winappxd from a DOS Command prompt using a line like:

        c:\appx> winappxd -s=8060

This should cause WinAppxD to use the currently logged in user's domain for authentication. If you were able to successfully run winappxd as a service before trying this, using this technique should not cause it to "break". If you read this FAQ prior to installation and decided to skip the whole process of running WinAppxD as a service, then please make sure that the APPX environment variables APPXPATH, APPX_SERVER and APPX_KEYMAP are set for your current command shell by doing a "set |more" before running winappxd.