Our company is upgrading from TFS 2013 to TFS 2015. We have set up the XAML Builds to work without any issues. now we want to start using the new process in 2015. We ave set up the build agents on a build server. When we queue up a build it fails without any reason why. The build when queued just states "Waiting for an available agent" for 2 minutes then fails. It seems like The build agent can't be connected to. We have made the service account running the build agent as System Admin on the Windows 2012 Server. I've added a pre-build step that updates a build version and the seems to be working as the first step. is there any diagnostic logs I can view?
First,please double check the step and configuration of your build agent following this tutorial: Deploy an agent on Windows After doing this, your vnext build agent pool and agent should all be green.
Make sure in your build definition you have select the right agent queue. Also try to create an empty build definition with no build task to see if the issue is related to the definition. And also restart your agent service on your TFS server.
Also check if the service Visual Studio Team Foundation Background Job Agent is running. If not, start it manually and try the build again.
Note: The servie is running in TFS server, not build server.
For logs to troubleshooting , check the event view and the log in \agent_diag on build agent to see whether there are some useful information.
Make sure the account that the agent is running under is in the "Agent Pool Service Account" role (http://tfsserver:8080/tfs/_admin/_AgentPool).
If adding the account to Agent Pool Service Account still doesn't work, try to change a domain account which is a member of the Build Agent Service Accounts group and belongs to "Agent Pool Service Account" role, to see whether the agent would work.
We figured out the issue. Somehow the folder permissions were not set correctly. so we removed permissions and reapplied which solved the issue.
Related
I am getting below error when trying to login into my AWS EC2 instance. Last login was around 2 weeks back and everything was working fine so the password I am using is correct. No other information is available on the error message.
Is there a way I can see any logs through management console ?
Appreciate any help on this.
Remote Desktop Connection
An authentication error has occurred.The function requested is not supported
It seems like you are facing this issue.
Bottemline, This is caused by a Microsoft Security Patch. The Microsoft Security patch issued on Tuesday, May 8th 2018 triggered the problem by setting and requiring remote connections at the highest level.
Simply adjust the Remote Desktop settings on the host machine to a lower security level. From File Explorer, choose Computer, right-click and select Properties, then click Change Settings, and go to the Remote tab.
From Windows 10, uncheck the option to “Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)”
From Windows 7, it’s setting the option to the Less Secure option rather than More Secure
Once these are set, users can remote to the machine again.
If you don't have any other way into the machine except Remote Desktop, I'm afraid the machine is lost.
For anyone facing this issue. Below is response from AWS technical support team:
Looking at the error message you posted, this is due to a recent patch (KB4103727) that Microsoft has released to fix a vulnerability. It is a mandatory requirement from Microsoft that both the client machine (the computer from which you are trying to RDP into your instances) and the remote server (your EC2 instance) has the latest updates installed. If one of these machines has the latest updates installed and the other does not, RDP connection would fail.
Note: If you see your Windows is up to date and you do not see the KB4103727 installed, it could be a different KB article which applied the KB4103727 as a cumulative update. If this is the case, please uninstall all KBs that were installed recently before the RDP connection was broken.
For more information about this hotfix, please refer to the Microsoft documentation below:
https://blogs.technet.microsoft.com/yongrhee/2018/05/09/after-may-2018-security-update-rdp-an-authentication-error-occurred-this-could-be-due-to-credssp-encryption-oracle-remediation/
https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018
There are multiple workarounds for this issue:
Option 1: If the update is installed on your client (workstation) and is not installed on your EC2 instance.
Uninstall KB4103727 from your client machine. After you uninstall the KB and gain RDP access to the EC2 instance, you can patch the instance with latest updates first and then update your client machine with the KB by running Windows Update again.
Alternately, you can keep your client machine updated and you can install latest Windows updates on your EC2 instance remotely using SSM Run Command. For detailed instructions on how to configure your instance to use SSM Run Command, please refer to the below documentation:
SSM Prerequisites: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-prereqs.html
Run Command Tutorial: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/tutorial_run_command.html#rc-tutorial-ui
After you configure your instance to use SSM Run Command, you can execute the Run Command document "AWS-InstallWindowsUpdates" remotely on your instance.
Option 2: If the KB is installed on your EC2 instance and is not installed on your client machine
Run Windows Update on your client machine and install latest software updates. Once the latest updates are installed on both your instance and the client machine, you should be able to RDP into the instance.
Alternately, if you have a backup AMI or an EBS snapshot created before the patch was installed on your EC2 instance, you may consider restoring your instance from the backup to roll back the installed software updates.
Option 3: There is a workaround suggested by third party websites to disable the check altogether on the unpatched Windows machine and RDP should work normally. On the unpatched machine, open a command prompt with Administrator privileges and run the command mentioned below:
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /f /v AllowEncryptionOracle /t REG_DWORD /d 2
Please note, you may have to reboot your Windows machine for the changes to take effect after you install/uninstall the KB.
So, finally I had to uninstall mentioned update from client machine(using which I was trying to connect to the aws instance) which allowed me to connect to the instance. Once connect, I updated the instance with windows updates and rebooted it which resolved the issue.
I just updated my Jenkins from 2.79 to 2.86
It seems to add new security fixes but it broke the EC2-Plugin
Indeed, now everytime the plugin is trying to launch a slave agent, I got an error:
"Launching agent" "ERROR: script not yet approved for use"
But the script to be approve via the Script Approval page is dynamic, containing temporary information
Did someone find how to solve the issue?
Thank you
EDIT:
I partially found a fix by unchecking the Connect by SSH Process in the EC2 configuration
Turn on sandbox mode. Whole-script-approval mode really should not be used any more.
While Used In a script, nothing else, only checkout, load the script and function call
Refer this
I also downgraded to 2.84 as I could not figure out how to enable sandbox mode.
Created new JIRA with Jenkins team.
https://issues.jenkins-ci.org/browse/JENKINS-47979
We were having the same issue while launching the slave agent via the SSH client process. As we were not able to quickly solve this, we've decided to downgrade Jenkins to version 2.84.
go to manage jenkins
got to IN-process script approval
approve pending scripts
and then launch the agent.
I am trying to install an MSExchange 2016 in an EC2 instance from scratch without success. By from scratch, I mean I start from a new EC2 instance without any AD yet installed.
I am not very familial with Windows Server. I got a lot of problem during the installation. By digging the web, I fixed a lot of them, but I think there is something I miss to succeed in my installation. Any help would be greatly appreciated
Here is the procedure I followed:
I created an EC2 Windows Server 2012RC2 instance
I created a simple Active Directory in AWS.
I provided the AD DNS to my Windows Server (via Network and Sharing Center, properties of Internet Protocol v4)
I joined the server into that AD (Via Control Panel > System and Security > System, change computer workgroup to the domain defined in my AWS Simple AD)
Restart computer
Log into the server as Administrator, with the AD domain
Download Exchange from here
Set-up the active directory, as in this procedure: https://judeperera.wordpress.com/2015/07/24/step-by-step-guide-for-installing-exchange-server-2016-preview/
The Step 4.1. of that procedure indicates to execute the following code
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
When I execute it, I get the following error:
I do not understand what I need to do/fix to continue the installation.
Thanks in advance for your help!
The issue you are encountering is that Simple Directory is not an Active Directory product, it is powered by Samba v4. What you need is to setup a Microsoft Active Directory (Enterprise Edition) or Microsoft AD, which is powered by Windows Server 2012 R2. The Simple AD is powered by Samba v4 and is simply Active Directory compatible but does not support the added schema features which are needed by Exchange Server 2016.
The other option is to back away from hosting your own instance of Exchange server and instead take a look at AWS WorkMail. It is an exchange like service which supports active sync with Outlook 2007+ and all current mobile smart devices such as Android and iOS. I currently use this and it took a lot of the headache out of managing my own mail server as the complexities are offloaded to the AWS environment and all you need to do it add mail accounts and group addresses.
Either option should solve your issue.
We are using Hudson to build mixed C++/Java projects with an Ant script. It is running in Tomcat 6, on a Win XP virtual machine.
I have noticed recently that when a user logs off the machine (from a remote desktop session), builds that are currently running tend to suddenly fail without an error message.
Has anyone encountered anything similar or have an idea what might be causing this effect? I can post additional information about our setup if needed, I'm just not sure what's relevant in this case.
EDIT: I have tried running the Tomcat service under various users, but this doesn't seem to help. Tried the standard Local System account, as well as the server Administrator and a domain administrator account.
Try adding -Xrs to the Tomcat JVM arguments.
For more information see this bug.
I have a project that is being built using CruiseControl.NET. The project contains an 'MSBuild task' that runs the build for the project and also the unit tests. The unit test in turn is just a MSBuild 'exec' task that runs an executable.
The unit test involves some .NET remoting. And when the unit tests are run through the system command prompt, the software's window opens up, tests run and the process exits.
When I force a build through the web dashboard, the build hangs at the point where the unit test starts running. The software's window does not open up, but the executable is running. If the process is killed through the task explorer, the build goes through with a 'Failure' status. This happens when I run ccnet as a windows service.
If I run CCNet directly (not as a windows service) and force a build through the web dashboard, the build and unit tests go through fine as expected. (with the window of the software opening up.)
It looks like there is a deadlock in the case where CCNet is run as a windows service. I am guessing it is related to the standard output/error streams.
Is this is known problem?
What might be the problem going on?
Any suggestions on debugging this?
How can I get around it?
(I am using CCNet version 1.4.4 SP1)
When CCNet is running as a service it is not going to have access to the display, so don't expect to see anything on the screen in this configuration. The first thing I would check is the permissions - make sure the service runs as an account that has permissions to access whatever resources you need. You also have CCNet log files, which you can find via Dashboard.
On a side note, try TeamCity instead of CCNet, its 10 years ahead.
Maybe this answer will help :
delphi windows service can't download file from internet
You should know that when running CCNet as an application (the dosbox) it uses the environment variables and all rights from the logged account. So it may connect to a server, use cached passwords, get registry variables for this account.
BUT when ran as a service, the account is the one you provided : LocalSystem for exampe, where env. varibales are not the same.
So, what you can do is to change the CCNet service account for test. Change it to your user account (with password), and I'm sure it will work better !