I am trying to configure Cruise control 1.8.5 to connect to Visual Studio Online to get the source to build and run tests, however whatever I do I always get the error 'TF30063: You are not authorized'
I have copied over tf.exe and required DLLs to the build machine as per one of the answers here (I would rather not install VS2013 on the build machine if possible, this is just a proof of concept at this point).
I have enabled alternative credentials as per here
This is part of the cc.net config - everything in square brackets has been double checked:
<sourcecontrol type="vsts">
<server>https://[account-name].visualstudio.com/DefaultCollection</server>
<project>$/[proj-name]</project>
<username>[alt-credential-username]</username>
<password>[alt-credential-password]</password>
<executable>[path-to-tf.exe]</executable>
<workspace>[workspace-name]</workspace>
<autoGetSource>true</autoGetSource>
<cleanCopy>true</cleanCopy>
<force>true</force>
<deleteWorkspace>true</deleteWorkspace>
</sourcecontrol>
I have tried my normal credentials, the alternative credentials, and even ##LIVEID##[alt-credential-username] as mentioned here
I always get:
ThoughtWorks.CruiseControl.Core.CruiseControlException: TF30063: You are not authorized to access https://[account-name].visualstudio.com/DefaultCollection
Note that I am able to connect manually from the build machine, e.g. running the following authenticates successfully and displays the expected directories under source control:
tf.exe dir /folders /server:https://[account-name].visualstudio.com/DefaultCollection "$/[proj-name]" /login:[alt-credential-username],[alt-credential-password]
(this works from both admin and non-admin cmd)
I also tried to run this to get a 'service account' however it crashes for me on Windows 7 x64
I have seen this however as I can manually connect using cmd/tf.exe I am assuming that tf.exe now does support alternative credentials...
I will probably try Team Explorer Everywhere 2013 tomorrow, although I'd rather avoid this due to it being Java based which I have no problem with apart from it's just another dependency / step in the setup.
Any tips/suggestions appreciated, as I'm out of ideas at this point!
UPDATE:
Using fiddler as suggested shows the following
tf.exe get from the command line is sending two requests:
1)
https://icb.visualstudio.com/DefaultCollection/VersionControl/v5.0/repository.asmx
soap body:
ReconcileLocalWorkspace [ xmlns=http://schemas.microsoft.com/TeamFoundation/2005/06/VersionControl/ClientServices/03 ]
with values for workspaceName, ownerName, pendingChangeSignature and maxClientPathLength
2)
https://icb.visualstudio.com/DefaultCollection/VersionControl/v5.0/repository.asmx
soap body:
Get [ xmlns=http://schemas.microsoft.com/TeamFoundation/2005/06/VersionControl/ClientServices/03 ]
with values for workspaceName, ownerName, requests, maxResults and maxClientPathLength
However CC is sending this request twice:
https://icb.visualstudio.com/DefaultCollection/Services/v1.0/Registration.asmx
soap body:
GetRegistrationEntries [ xmlns=http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Registration/03 ]
with toolId=vstfs
Short answer: Run the cruise control .net service as the same user you used to create the workspace (not the local system account).
Details:
I ended up getting the cruise control .net source, and attaching a debugger to see exactly what tf command was generating the error.
The process info that was failing:
Executable = "...tf.exe"
args = {dir /folders /server:https://[account-name].visualstudio.com/DefaultCollection "$/[proj-name]" /login:[alt-credential-username],[alt-credential-password]}
workingDirectory = "[valid-working-dir]"
Running this command manually worked fine - which led me to check the cc service properties, which were set to log on as Local System Account. I updated this to log on as the same (Windows) user that I used to create the workspace and this fixed the problem.
I can only assume that tf.exe is doing something clever with accounts/credentials or maybe it's just that workspaces are tied to particular windows logons?
Thanks to Edward for suggesting I fiddle with fiddler.
Related
I'm working with the following:
Docker for Windows v20.10.11
Docker running in Windows container mode
mcr.microsoft.com/windows:1903 base image
Proprietary application installed on top of this base image
Each year we create a Docker image with the latest version of our company's software. However this year's version behaves differently. Host machine installation runs fine. Containerized installation fails to run in certain situations. I can start the application as a simple EXE, for example using the Docker run command. The app will start and show up in "tasklist". However I can't start the app via the COM API, which is a critical requirement. The problem appears to be COM related. Normally we can create COM objects for our software just like for any other application. For example, IE returns a COM object just fine:
Creating these objects for our application works outside containers. However inside the container, our latest installation gives this error:
Access permissions appear to be ok. I tried a couple tests to prove this. First I can install other software like MS Word into a container and create COM objects for that:
Second I tried retrieving + modifying the application's DACL in PowerShell.
Changing access masks or trustees can cause an Access Denied error:
This also appears to confirm the access permissions were Ok by default.
Next I made sure COM is aware of the application. This appears to be fine. I get the same result on host machine and container when running this PS script:
gci HKLM:\Software\Classes -ea 0| ? {$.PSChildName -match '^\w+.\w+$' -and
(gp "$($.PSPath)\CLSID" -ea 0)} | ft PSChildName
The application shows up just like any other. The details show up fine when querying by AppID. LocalServer32 points to the correct EXE:
Some other things I tried:
Querying registry keys. There are 7 keys created when installing our software. These appear identical on host machine install and container install.
Even though permissions appear fine, I still tried logging into the container as alternate users. For example "nt authority\system" is another virtual admin user. I also changed the password of the "builtin\administrator" user to enable logging in with that one. Lastly tried creating new users entirely and adding them to the Administrators user group. All these attempts had the same errors as "builtin\containeradministrator" (default user).
A minor check was ensuring CMD.exe / Powershell is running as x64:
Re-registering the DLLs associated with the installation using regsvr32.
Starting from different base images. https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images. The full Win Server base image behaves exactly the same way regarding errors. The smaller Win Server Core base image is even more problematic, as I can't even start the app's EXE manually using that base. Lastly I tried other tags of the full Windows base image such as 20H2 and 2004. Same result from those. Multiarch or x64 makes no difference.
Included the "Ogawa hack" which was historically needed to make MS Office apps function correctly with COM: https://stackoverflow.com/a/1680214/7991646. It could be necessary for other COM apps too, but didn't help with my specific installation.
Is there anything else I can do to diagnose or solve this COM issue?
There are several things to consider:
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
The When CoCreateInstance returns 0x80080005 (CO_E_SERVER_EXEC_FAILURE) page describes possible reasons.
If many COM+ applications run under different user accounts that are specified in the This User property, the computer cannot allocate memory to create a new desktop heap for the new user. Therefore, the process cannot start. See Error when you start many COM+ applications: Error code 80080005 -- server execution failed for more information.
Finally, you may find a similar thread here helpful, see Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
In the Rest Webservice Command, I don't see any option to pass a variable in the URI.
We do not want to hard the end point in the script.
As an e.g I will want the script to use different points for dev/stage and prod.
Is there a work around for this.
On building a URI with variables like :
https://$v_hostname$/test-rs-v1/employee/data send request works fine but
bot runs we get an error stating :
Hostname could not be parsed.
Update: That was a bug and fixed on version 11.3.1. You can only achieve that on version 11.3.1 or later.
Reference: https://docs.automationanywhere.com/bundle/enterprise-v11.3/page/topics/release-notes/release-notes-11-3-1.html
Workaround for older versions (If you have experience with C#): Build and test DLLs
The following applies only on version 11.3.1 and later.
Make sure that $v_hostname$ contains a value at the run time, using debugging option or message box command.
I did reproduce the same error by entering a variable that doesn't exist or doesn't have a value, there is no another scenario would reproduce "Hostname could not be parsed".
If the hostname/URL is invalid you will get "The remote name could not be resolved:".
I've tested the REST Web Service command on both community and enterprise editions, and it's working very well.
I have been working on restoring a build server (tfs 2012) from a backup and all manner of things got messed up (the tfsservice account password had been altered and I had to go to every service and app pool on the box and update it). Once sql was backup I was able to update the password via the TFS admin console app. Then I was able to re-register the build service and add a controller and a build agent. It starts briefly and shows green for a few seconds before stopping and a "details ..." button appears next to the Build Service. If I click the details button I see the following
"Please contact your administrator. There was an error contacting the server. Technical information (for administrator): HTTP code 500: System.ServiceModel.ServiceActivationException"
I have checked the http bindings in iis for the tfs site and there is only the one "*:8080"
I tried hardcoding it to the ip on the box and I still get the same error. If I go to one of the client machines and try and queue a build it shows the build server as being offline.
I have also checked for multiple host headers and the memory utilization which are the most common responses to this particular issue. Neither of them seem to be the cause or the solution.
Any ideas or suggestions are welcome I have run out of ideas to try here. Thanks in advance for any help you have to offer.
EDIT -- also found this in the log: Build machine MyMachine lost connectivity to message queue tfsmq://buildservicehost-25/.
I have been attempting to run a Unit Test in visual studio for an MVC Application and continuously getting the following error:
The URL specified ('http://localhost:21496/') does not correspond to a
valid directory. Tests configured to run in ASP.NET in IIS require a
valid directory to exist for the URL. The URL may be invalid or may
not point to a valid Web application.
The only advice around is to make sure you have a localhost address in the UrlToTest attribute like so:
[TestMethod()]
[HostType("ASP.NET")]
[UrlToTest("http://localhost:21496/")]
This however still doesn't run against IIS Express or IIS 7 on Windows 7 and when I delved into the event logs, found the following problem.
(QTAgent32.exe, PID 6976, Thread 15) WebSites.GetWebServer: failed to create AspNetHelper: Microsoft.VisualStudio.Enterprise.Common.AspNetHelperException: The website metabase contains unexpected information or you do not have permission to access the metabase. You must be a member of the Administrators group on the local computer to access the IIS metabase. Therefore, you cannot create or open a local IIS Web site. If you have Read, Write, and Modify Permissions for the folder where the files are located, you can create a file system web site that points to the folder in order to proceed. ---> System.Runtime.InteropServices.COMException: Unknown error (0x80005000)
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_IsContainer()
at System.DirectoryServices.DirectoryEntries.ChildEnumerator..ctor(DirectoryEntry container)
at Microsoft.VisualStudio.Enterprise.Common.IISHelper.GetWebServerOrdinal(Uri site)
--- End of inner exception stack trace ---
at Microsoft.VisualStudio.Enterprise.Common.IISHelper.GetWebServerOrdinal(Uri site)
at Microsoft.VisualStudio.Enterprise.Common.IISHelper.get_WebServerOrdinal()
at Microsoft.VisualStudio.Enterprise.Common.IISHelper.get_RootPath()
at Microsoft.VisualStudio.Enterprise.Common.IISHelper.get_PhysicalPath()
at Microsoft.VisualStudio.Enterprise.Common.AspNetHelperMan..ctor(Uri uri, BasicAuthCredential credential, Int32 frameworkMajorVersion)
at Microsoft.VisualStudio.TestTools.HostAdapters.WebSites.GetWebServer(String webServerName, WebServerType webServerType, String urlToTest, String pathToWeb, String webAppRoot, BasicAuthCredential credential, Context context, WebSiteConfigurationType webSiteConfigType, Origin origin)
The next step I took was to make sure the QTAgent32 always runs with administrative privileges, along with visual studio.
I am now at a loss and cannot think of anything else to try, so do hope someone can at least point me in some direction.
Thanks
The tests were created in a default ASP.NET environment. In order to test the controllers but without the need to run the web application, you must delete the following attributes before the test methods.
[HostType("ASP.NET")]
[UrlToTest("http://localhost:21496/")]
I ran into the same problem today (also at this thread). I had the same errors in my event log:
(QTAgent32.exe, PID 12348, Thread 61) WebSites.GetWebServer: failed to create AspNetHelper: Microsoft.VisualStudio.Enterprise.Common.AspNetHelperException: The website metabase contains unexpected information or you do not have permission to access the metabase. You must be a member of the Administrators group on the local computer to access the IIS metabase. Therefore, you cannot create or open a local IIS Web site. If you have Read, Write, and Modify Permissions for the folder where the files are located, you can create a file system web site that points to the folder in order to proceed. ---> System.Runtime.InteropServices.COMException: Unknown error (0x80005000)
That lead me to this blog post which seems to have resolved the issue.
I just needed to go to "Turn Windows features on or off" and add IIS 6 Management Compatibility and all four subcomponents. I'm running Windows 7 Home Premium which doesn't have the Windows Authentication option, but that didn't seem to be an issue. Give it a shot and see if that resolves the issue for you.
I'm trying the WorkSpace.PendAdd method under Microsoft.Teamfoundation.Client namespace to add the local folder to TFS, it works normally when i debug with VS2010, but it doesn't work if it's published to IIS. I also tried giving the full control to the folder, but still no effect. Any idea will be appreciated.
Check to see what identity the web app is running under. Does that ID have appropriate rights in TFS? If you're hosting on a web server that is not also your TFS application tier, you could also be running into the two-hop limitation of passing identity.
When you're running in debug mode, it is probably picking up your credentials, and since your machine counts as hop zero, there's no problem passing them on to the TFS application tier.
I found a solution after checking the versionControl NonFatalError event.
Before the calling to workspace.PendAdd, just call:
Workstation.Current.EnsureUpdateWorkspaceInfoCache(
_versionControl,
_versionControl.AuthenticatedUser);
(for some reason it's the only way the specific file folder path will be mapped when running in IIS)