App Uninstall Failing Using Product Code

I'm working on a perplexing uninstall/install issue and I've exhausted my google-foo so I'm coming here hopeful that someone can point me in the right direction.

The scenario: We are using AnthillPro to do nightly builds/deployments of a legacy ASP website (built in VS2003) to Windows Server 2003 (x64 SP2) web servers and for the most part it works fine. The AnthillPro account uses the product code to uninstall the previous night's update package and then installs the new one using the name of the MSI. We are all updating the product code with each new release (roughly every two months).

This works just fine on our QA and Production web servers, but the dev server always gives us the error:

Code:

The installation source for this product is not available. Verify that the source exists and that you can access it.

The most interesting detail about this is that when the AnthillPro account installs it, I cannot see the update in the Add/Remove Programs widget. Not only can I not see it, but I am allowed to install it myself. If I do so, it does show up in Add/Remove Programs with a size double of what it should be (in other words, it seems to be installed twice). I originally discovered this issue a few weeks ago and thought I fixed it by manually adding the ALLUSERS property to the MSI and setting it to 2. Again, this is a Visual Studio 2003 solution, so I can't just set the All Users property through the interface.

I am able to see the latest update on QA and Prod, however, so it seems to be something special with the dev box. I've confirmed that the resulting MSI does indeed have the ALLUSERS property, and I've tried playing with setting it to 1 instead of 2 (per this discussion).

The MSI is being overwritten with each build, so it is true that the original MSI is not sticking around in the directory the install is being executed from, but if I simply try redeploying what is already there, it still fails.

If I log in to the dev web server and install it myself, making sure that the All Users option is selected in the UI, it exhibits the same behavior if I try another automated deployment. If I ensure that the update is not installed on the box and kick off an automated deployment, it will succeed (after kicking out a warning about the uninstall not being able to uninstall anything), but will then fail with the "source is not available" error if I try another automated deployment after that.

The permissions on the folder containing the MSI and the MSI itself appear to be identical between dev, QA, and Prod. I do not have the password for the account that AnthillPro uses unfortunately (hooray for corporate security), but I at least do have access to someone who does and is willing to check on things if I am so inclined. I did confirm using this method that when I install the latest version of the update that the AnthillPro account can see it.

I have looked into many possible solutions/tools, one of which was MsiInv, but that tool couldn't find the hidden install either.

Does anyone have any ideas on what could be causing this issue?

I posted this on stackoverflow late last week, if anyone is interested in answering through that medium. I've modified the post and added a few details since that posting on SO.

This is obviously a very strange issue and I don't actually expect anyone to have any ideas; I'm just desperate and the very process of writing this out maybe will trigger some more ideas for me.

This account is part of a different domain than the one that the web server is in and apparently the account doesn't have the right permissions to use the ALLUSERS property. Lets call the domain that the service account is in "X". I actually log in to the web server using an "X" account as well but I have admin rights. I went as far as creating an account on the web server that was only in the Users and Remote Desktop Users groups (no admin) and tried installing the update with that account and the ALLUSERS property was left alone.

This would explain why I can't see the update in Add/Remove Programs when the service account installs it and would be a very plausible explanation for why the uninstall for the service account always generates the

Code:

The installation source for this product is not available. Verify that the source exists and that you can access it.

error. This happens even when the update it is trying to uninstall isn't there (i.e. I would expect the error to be "This action is only valid for products that are currently installed.").

My question now--which hopefully is a little easier--is how to I go about checking what permissions this other account in domain X has on this web server box in domain Y? For that matter, how do I check my own rights on this web server box? Once that is known, how do I go about updating those permissions so the ALLUSERS install will work (I'm assuming the account will need admin rights)? I don't have much experience with active directory admin tasks (if that isn't apparent already), and I very highly doubt I have access to modify anything at a broader level than individual boxes (I'm a consultant for this company).

Anyways, I'd appreciate any points in the right direction, this latest rabbit hole has proven difficult to google for ("check permissions different domain account"????).

Fast way to list the permissions on a file or folder from a command line:icacls <Path>

Such as:icacls C:\Temp

Thanks for that, it confirmed what I heard from somebody else: that this account is part of an AD group that is a member of the Admin group on the box in question.

I've continued to bang my head up against this issue and think I have some more useful information, but still haven't figured it out exactly. I looked through the verbose installation logs again and noticed that for the service account in question, this line shows up almost right before the deletion of the ALLUSERS property:

Code:

Determined that existing product (either this product or the product being upgraded with a patch) is installed per-user.

That reminded me that the original install of this product did not have the ALLUSERS property defined, so that could make some sense. I uninstalled all versions of the app, modified the original setup package (via ORCA) to include the ALLUSERS property (set to 2) and tried again. Unfortunately, it still didn't result in a better outcome.

I vaguely recall reading somewhere in the tens of threads/pages I've looked through about this issue that individual user accounts can somehow get hosed up and hold on to old install settings, especially if an application that is installed by that user is uninstalled by somebody else (which could well have happened in this case). Has anyone ran into this before? Know if this has any truth to it? If so, any way around it?

Ok, I finally (!!!) got this working. What I ended up doing to get it working was:

Uninstall every version of the appSearch through the registry for any references to the upgrade code, product codes for each version that was installed, and the name of the appDelete all such references found (I exported the keys first)Reinstall from the beginning, making sure all previous versions had the ALLUSERS property set to 2

I don't know why I didn't try this brute force method earlier, but at least I got to it eventually. Still don't know the root cause, but I don't really care anymore. It works!