While uninstalling a VS2010 setup project I'm developing which installs a service, I am receiving the following error (taken from the verbose MSI logging):
MSI (c) (60:90) [13:37:59:038]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1402. Could not open key: UNKNOWN\Components\216B73E88467B322BBFF14C949E03D05\F1DB4DDE64042404E8863AB2CA9520DF. System error 5.
Verify that you have sufficient access to that key, or contact your support personnel.
MSI (s) (84:A4) [13:38:01:678]: User policy value 'DisableRollback' is 0
MSI (s) (84:A4) [13:38:01:678]: Machine policy value 'DisableRollback' is 0
Action ended 13:38:01: InstallExecute. Return value 3.
Note that this service is installed using a local machine account or a domain user account. It DOES NOT use the built-in account such as Network Service, Local System, or Local Service.
Using the Windows Installer Verbose Log Analyzer (wilogutl), it tells me that this section of code is the first error from the installer log. Furthermore, it tells me the possible solutions:
A standard action or custom action
caused the failure.
Installer Version: 5.0.7601
Client Side Privilege Details: None
Server Side Privilege Details:
MSI (s) (84:A4) [13:37:55:306]:
Product
{EDD4BD1F-4046-4042-8E68-A32BAC5902FD}
is managed. MSI (s) (84:A4)
[13:37:55:306]: Running product
'{EDD4BD1F-4046-4042-8E68-A32BAC5902FD}'
with elevated privileges: Product is
assigned.
I've tried running ProcMon to try and diagnose the problem but no luck. The installer seems to run no problem. The installer uses a custom action (C# InstallerClass) to install the service. The system cannot uninstall the service on my machine however.
Update 1:
Here is the human-readable error from the logs:
(SERVER) MSI (s) (84:A4) [13:38:02:186]: Product: MyService -- Removal failed.
(UNKNOWN)
(SERVER) MSI (s) (84:A4) [13:38:02:186]: Windows Installer removed the product. Product Name: MyService. Product Version: 1.0.0. Product Language: 1033. Manufacturer: ManufacturerName. Removal success or error status: 1603.
(UNKNOWN)
(SERVER) MSI (s) (84:A4) [13:38:02:187]: Deferring clean up of packages/files, if any exist
(SERVER) MSI (s) (84:A4) [13:38:02:187]: MainEngineThread is returning 1603
And the error 1603 can be interpreted as the following (although this is not shown in the log):
The file [2][3] is being held in use
by the following process: Name: [4],
Id: [5], Window Title: '[6]'
Okay, I got some assistance from another developer and the problem turned out to be that the user account used to install the software was a Domain User account which had access to create registry keys but not the permissions to delete them during the uninstall.
This process left a lot of keys in the registry that cause problems on uninstall/reinstall.
The solution was to add myself as a local user account under Computer Management. Next I had to assign this user to the Users and Administrators group (just for good measure). Finally, I had to go into the registry and find all remnants of the software registry keys and forcibly delete them.
This was no easy feat because the process of deleting a key involved about six steps when you right-click and select Permissions on a key value:
Granting full access to the Administrators account
Granting full access to the Users account
Click the advanced and add my domain user account
Going to the Owner and "attempting" to add the Administrator as owner (w/Recursive children applied)
Back to the users tab, grant full control to my domain user account
Click OK and OK and then I can delete the key
Related
I am trying to get some automatic deployments up and running using TFS 15 (on-premise). I have a powershell script on the deployment target to call.
The deployments starts fine by downloading the artifact. But when the agent runs the script it wants to create a folder C:\Windows\DtlDownloads (thats not part of my script but part of preparing things for TFS I guess). That fails:
##[debug]System.AggregateException: Failed to install 'VisualStudioRemoteDeployer20597940-38b2-4ba8-9a4d-fcc894308730' from service executable path VisualStudioRemoteDeployer.exe . Consult the logs below:
Access to the path 'DtlDownloads' is denied.
CategoryInfo :PermissionDenied: (C:\Windows\DtlDownloads:String) [New-Item], UnauthorizedAccessException
FullyQualifiedErrorId :CreateDirectoryUnauthorizedAccessError,Microsoft.PowerShell.Commands.NewItemCommand
The user used to logon is a server-local user named deploy who is also a local administrator on that machine. I also checked the effective access for that user on the windows folder and it should be able to create directories.
Something similar happens with the copy step. Robocopy signals two errors:
2017/03/16 08:57:21 ERROR 5 (0x00000005) Getting File System Type of Destination \\server.domain.com\c$\abc\def\
Access is denied.
and
2017/03/16 08:57:21 ERROR 5 (0x00000005) Creating Destination Directory \\server.domain.com\c$\abc\def\
Access is denied.
The second is a bit unexpected as the folder def already exists but I guess it is a follow up because getting the type failed beforehand.
The user itself must have been recognized because I get different errors when using invalid credentials. I have enabled WinRM using Enable-PSRemoting and ConfigureWinRM.ps1 from WinRM-Http-Https-Without-Makecert.
What could still restrict the permissions?
Update: Using a domain user instead of a local one of that server solves the issue. But I do not understand why. Can someone explain or even provide information how to make it work with a local user?
The username of either a domain or a local administrative account on
the target host(s).
Formats such as username, domain\username, machine-name\username, and .\username are supported.
UPN formats such as username#domain.com and built-in system accounts such as NT Authority\System are not supported.
Source Link
Both the domain account and local admin should be work. Please double check your format and give a try with another format.
One problem could be if that you have the agent as a service, that service has not the proper privileges, like being on Network Account. Try to change that to the user account which has administrative privileges.
Running "winrm quickconfig" fixed this problem for me
winrm quickconfig
https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management
I am trying to connect my Deployment agent to RM client from different domain. I created a shadow account and all other .Still it is not working. I am able to connect with same domain. My RM client and server is in same machine (VM). and my deployment agent is in different workgroup domain.(everything is in VM's) I am getting below error from the log file.
Created Nt account for user RM.user1
Found Sid S-1-5-21-2704102820-366803756-3152234569-1011 for user RM.user1
Is RM.user1 network service account? False
Created Nt account for user RM.user1
Found Sid S-1-5-21-2704102820-366803756-3152234569-1011 for user RM.user1
Is RM.user1 local system account? False
Domain:
Final UserName: SVWP500\RM.user1.
Loading account details for SVWP500\RM.user1
Is SVWP500\RM.user1 local machine account? True
Normalized account is SVWP500\RM.user1 and Sid is S-1-5-21-2704102820-366803756-3152234569-1011
Validating account to use as identity for Release Management Services...
IsAdminAccount : Trying to determine if the account : SVWP500\RM.user1 is an admin on the local machine
IsAdminAccount : Trying to determine if the account : SVWP500\RM.user1 is an admin on the local machine
User SVWP500\RM.user1 is system, Admin
Validated account to use as identity for Release Management Services.
Validating Release Management Server for Team Foundation Server 2013....
ServiceUserIsServiceUser="1" InstallerUserIsReleaseManager="1" />, Release Management Server for Team Foundation Server 2013 validation succeeded.
Received Exception : System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
at System.Security.Cryptography.Utils.SetKeySetSecurityInfo(SafeProvHandle hProv, CryptoKeySecurity cryptoKeySecurity, AccessControlSections accessControlSections)
at System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, CspParameters parameters, Boolean randomKeyContainer, Int32 dwKeySize, SafeProvHandle& safeProvHandle, SafeKeyHandle& safeKeyHandle)
at System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair()
at Microsoft.TeamFoundation.Release.CommonConfiguration.Helpers.CryptoHelper.<.ctor>b__2(CspParameters container)
at Microsoft.TeamFoundation.Release.CommonConfiguration.Helpers.CryptoHelper.ConfigureDeployerCryptoKey(String userName)
at Microsoft.TeamFoundation.Release.CommonConfiguration.DeployerConfigurationManager.Configure()
at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
Work completed for GetConfiguration() call : got out of turn error
Please help on this.
Looks like the account you are using to register the deployment agent hasn't got the permission to access to release management. Because next step after Team Foundation Validation is updating deployment configuration.
I, 2015/02/13, 08:25:54.156, Release Management Server for Team Foundation Server 2013 validation succeeded.
I, 2015/02/13, 08:25:54.236, Updating Microsoft Deployment Agent 2013 configuration settings...
V, 2015/02/13, 08:25:54.238, Successfully read Release Management deployer registry key, installation path is C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\
V, 2015/02/13, 08:25:54.251, Opening configuration file C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\bin\Microsoft.TeamFoundation.Release.Data.dll.config
I have a similar step up and below are the steps I did to make it work in my environment
Create a local user (RMServer) on both DomainA\RMServer & DomainB\DeploymentAgentServer machines. Add the users to administrators group
Create a local user (DeployAgent) on both DomainA\RMServer & DomainB\DeploymentAgentServer machines. Add the users to administrators group
From Release Management client add .\RMServer account and grant both "Service User" and "Release Manager"permissions (please note on windows account test box don't use machinename\user, just add .\user)
From Release Management client add .\DeployAgent account and grant "Service User" (please note on windows account text box don't use machinename\user, just add .\user)
Install the Deployment Agent on DomainB\DeploymentAgentServer as DeployAgent user (created in step 2)
I was using the Microsoft & Wouter de Kort blog
Is anyone successfully using MsDeploy for deploying windows services with a preSync runCommand? I've got it working using an Administrator account, but can't for the life of me get it working on a standard user account. Unfortunately I can't use integrated authentication (we're deploying to an external box), and the thought of our Administrator password sitting in plaintext in logs on our build server doesn't exactly make me feel too comfortable. For that matter, neither does any user credentials - but I can't see a way around that.
The command I'm using is this:
"tools/deploy/msdeploy.exe" -verb:sync
-preSync:runCommand="tools\Deploy\PreSyncCommand.cmd",waitInterval=30000
-source:dirPath="C:\BuiltSourcePath"
-dest:computerName=https://server:8172/msdeploy.axd?site=dummysitename,userName=service-deploy,password=service-deploy-pass,authType=basic,dirPath="C:\DeployPath\"
-allowUntrusted
with rules set up in IIS for the dummy site to allow the authentication for the service-deploy windows account, with contentPath and runCommand permissions (for the moment set to C:\ as it's not entirely clear whether this needs to be set to the temporary path that MsDeploy streams to, or the deployment path?). The service-deploy account also has full control of the target directory. I get the following back:
Performing '-preSync'...
Info: Using ID '7a7d34a1-b5d8-49f1-960a-31c9cf825868' for connections to the remote server.
Info: Using ID '4d0b910c-aca4-4640-84bd-3597d22d99d1' for connections to the remote server.
Info: Updating runCommand (C:\TeamCity\buildAgent\work\aec989676b349656\tools\De
ploy\PreSyncCommand.cmd).
Warning: Access is denied.
Warning: The process 'C:\Windows\system32\cmd.exe' (command line '/c "C:\Windows
\ServiceProfiles\LocalService\AppData\Local\Temp\giz2t0kb.0ay.cmd"') exited with
code '0x1'.
This happens even if the contents of PreSyncCommand.cmd is blank. The same command runs fine if I pass in Administrator credentials. I've tried using ProcessMonitor to check if anything's being denied access but can't see any - so I'm guessing it's still a MsDeploy authentication rule. There's nothing in WmSvc.log (debugging is enabled), nor in the event log.
Any ideas? Thanks!
Since you're using Web Deploy via WmSvc, you need to setup appropriate delegation rules on the destination server:
Within IIS Manager, open the "Management Service Delegation" feature. Add a new rule which at least specifies the runCommand provider. In the Run As section, choose Specific User and provide credentials for a local administrator account on that machine. This is the identity under which your runCommand scripts will be executed. Finally, the user which you're specifying for the destination dirPath provider needs to be added to the delegation rule.
That allows you to invoke a deployment using a non-privileged account, and yet have it executed on the target machine under administrative credentials.
More information on IIS feature delegation: http://learn.iis.net/page.aspx/516/configure-the-web-deployment-handler/
When I try to start Build Service from Administration Console I receive
TFSBuildServiceHost failed to start
correctly
and the event log reports
Service cannot be started.
Microsoft.TeamFoundation.TeamFoundationServerUnauthorizedException:
TF30063: You are not authorized to
access
http://localhost:8080/tfs/defaultcollection.
My build configuration settings are as follows
Connect to Team Project Collection
(outgoing) :
http://localhost:8080/tfs/defaultcollection
Local Build Service Endpoint
(incoming) :
http://localhost:9191/Build/v3.0/Services
Run Build Service As :
Windows Service
Credentials :
NT AUTHORITY\NetworkService
I have a default Build Controller and 1 Build Agent, with working Directory $(SystemDrive)\Builds$(BuildAgentId)$(BuildDefinitionPath). Both are enabled
My Security Setting are as follows
Application Tier > Service Account : NT AUTHORITY\LOCAL SERVICE
Team Project Collections > DefaultCollection > Group Memeberships > [DefaultCollection]\Project Collection Build Service Accounts : Contains NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\SYSTEM
IIS > Sites > Team Foundation Server > tfs : Contains NT AUTHORITY\NETWORK SERVICE (full control)
C\Builds\ : Contains NT AUTHORITY\NETWORK SERVICE (full control)
C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier : Contains NT AUTHORITY\NETWORK SERVICE (full control)
So I am not sure what else I am missing?
I managed to get this problem resolved by reinstalling TFS (not ideal).
The short answer, I think, to resolve this is to follow the steps for changing the Build Service Account, instead.
http://msdn.microsoft.com/en-us/library/bb909750(v=vs.90).aspx
It appears the problem was that I did not pay close enough attention during the Build Service Configuration stage of the installation, in particularly the health check step, which gave a warning that the specified service account, under which the Build Service would execute, must be added to Windows Credentials Manager. The warning further stated that, if I chose to use the current interactive user (i.e. my account, instead of an account I specially created for the Build Service) that the installation could do this for me, otherwise I would have to do it manually. Since I had already wasted two days on this, I chose to use my account instead and let the installation perform the necessary security setup, luckily !! since it appears that, adding the account to Windows Credential Manager is not the only thing you have to do, nor is any other seemingly logical thing, such as adding the account to the Team Project or Project Collection. I subsequently tried to manually change the account to a dedicated TFS user account, by assigning it to the Build Service, added it to Windows Credentials Manager and Team Project Collection, but no luck. I think the problem is that the account must also be specified for the WCF end points that TFS exposes to allow the build service to connect to it and I think this can be done through wcfhttpconfig.exe as mentioned in the link.
I'm trying to install Team Build (2008) on a different Build Server (BS) to the Application Tier (AT). BS is a 32-bit Windows 2008 server (as is the AT). They are on a corporate domain.
The EXE in question is
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies>
TFSBuildService.exe
The service on BS cannot start - the error is "Windows could not start the Visual Studio Team Foundation Build service on Local Computer\r\nError 5: Access is denied.". There is NO additional information in the Event Log. It is set to run as DOMAIN\TFSSERVICE account, which is also added to the Local Administrators group. It fails very quickly.
When I try to run it 'interactively' - the error on the command line is "Program too big to fit in memory".
It seems to me like this should be a fairly simple thing to set-up and use. What am I missing?
Notes:
I got my .config from Buck. I'm pretty sure I've correct set the ports, Windows Firewall rules
I can access the web services on AT from BS via Internet Explorer (using the DOMAIN\TFSERVICE login)
I've added DOMAIN\TFSSERVICE user to a TFS project's Build Services group
I have checked DOMAIN\TFSSERVICE has full permissions on pretty much everything on the Build server.
Try this:
Associate the default port to the new build service account using the wcfhttpconfig.exe command-line tool located in the following folder:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies
Execute (from the folder above):
wcfhttpconfig.exe reserve DOMAIN\UserAccount 9191
Full credit from the following post:
http://wesmacdonald.spaces.live.com/Blog/cns!25108A9ADA96C9D7!1553.entry
I suggest you should set up a dedicated TFSBUILD account and not use the TFS Service account for this task as a best practice.
OK, the fact that you can access web services using the TFSSERVICE account from BS through to AT is a good thing, I am making the assumption you have created a LOCAL account on the BS machine for the TFSSERVICE account?
If not, please:
add a LOCAL account with the same name as DOMAIN\TFSSERVICE.
ensure that the password matches that of the DOMAIN\TFSSERVICE account.
ensure that account has "log on as a service" right under Local Security Policy.
Please read article: http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/d519b8e3-451a-4f07-97b1-e2943c2756c2
My issue was that my passwords for the AT and BS machine had to MATCH on the same domain. Please double-check that the TFSSERVICE account password matches on both the AT and BS machine, as the service will use impersonation when on the same domain.