Following the guide and powershell script from this article,
https://www.windowsazure.com/en-us/develop/net/common-tasks/continuous-delivery/
I've run into an extremely odd error:
9/4/2012 9:02 PM - Creating New Deployment: In progress
New-AzureDeployment : There was no endpoint listening at https://management.core.windows.net/5921d8af-88a1-4f63-9673-5e1ae1df7e8a/services/storageservices/Build_2012-09-04_02-27.1/dist/LNEC_Admin.Azure.cspkg/keys that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
It's odd because we're on build "Build_2012-09-04_08-16.1", not the one mentioned in the URL above (which no longer even exists on the filesystem). This is under Jenkins CI which runs under the NETWORK SERVICE account. If I run it by hand with my own account the same error results, but with a lnecint in place of the build directory: https://management.core.windows.net/5921d8af-88a1-4f63-9673-5e1ae1df7e8a/services/storageservices/lnecint/keys
That keyword "lnecint" isn't mentioned anywhere in any config (I've searched every file on the entire machine and TFS server). It was the name of a storage account, but it's long ago been deleted.
VS 2012, Azure SDK 1.7.1
There's definitely an issue with your endpoint. Can you check what parameters you're passing to the "New-AzureDeployment" Cmdlet?
Related
I have a C# console app that I wrote that is trying to enable mail for an AD user.
using (Runspace EnableMailboxRunspace = RunspaceFactory.CreateRunspace(ConnectionInfo(ExchangeServerURI, ExchangeUser, ExchangePassword)))
{
EnableMailboxRunspace.Open();
// Create a pipeline to process the commands
using (Pipeline EnableMailboxPipeline = EnableMailboxRunspace.CreatePipeline())
This works just fine in the dev environment, but I cannot get it to run on any production server. When the CreatePipeline command is executed I get this error:
"Connecting to remote server pc799.csnt.princegeorge.ca failed with
the following error message : The WinRM client cannot process the
request. It cannot determine the content type of the HTTP response
from the destination computer. The content type is absent or invalid.
For more information, see the about_Remote_Troubleshooting Help
topic."
I have tried this running as multiple different users, including domain admins.
This app did work a few months ago, but now it doesn't work. We moved from a fully on prem system, to a hybrid M365/On prem system and something in that seems to have broke it.
We are using on site Dev-Ops and have a similar problem to that described in the link Example from SO.
But ours is intermittent.
Our environment uses two build and deploy machines, which each deploy machine having two worker agents.
For one of our projects, when it is deployed, we constantly get the error:
The VisualStudioRemoteDeployerc4d3852f-411b-48ba-97d8-5e09c8d07ce4 service failed to start due to the following error:
%%2
But here is the rub, not every time. Sometimes the deployment completes without error.
Other projects that use the same deployment machine and the same target server work each and every time without fail.
The deployment log reports "The WSMan provider host process did not return a proper response." as an error.
Checking the allocated memory, described in PowerShell Out of Memory, to find our set at 2.1 Billion.
This is an interesting issue that I have uncovered. The source of this problem stems from the interaction of McAfee Endpoint security.
Said antivirus was reporting that when the remote powershell script, using WSMan, was called. McAfee, saw this as a viral payload and canceled the deployment by stopping the service from running and deleting the payload. This has been reported to McAfee as an issue. In the mean time, internal network security settings for McAfee has had to be modified to ignore the processes used by powershell in remote deployment.
I configured the build agent as a service but when I go to start the agent I get the error:
Error 1 Incorrect Function - Service could not start
Azure DevOps Agent configured as a service but service does not start
I changed my user to Local System (NT AUTHORITY\SYSTEM) in services.msc and it worked as intended.
Copied from the comments:
ok ill answer my own question, when the config.cmd command is run, it
allocates the network service as the account to run the service.
However it does NOT automatically give permissions to where the agent
folders are installed. So it fails to run. Stupid as this should be
flagged when running the config.cmd command! The error message is
nonsense and misleading. So if the agent is in c:\users\abc\agent you
need to give the network service permissions to access that folder!
Running from C:\Agent worked perfect for me after struggling for a few days.
This happens when the service Azure Pipelines Agent in the machine is set with Log On As NETWORK SERVICE.
To resolve this, we need to
Right Click on the Azure Pipelines Agent
Properties
Click on LogOn tab
select Local System Account
The final output should be as per the attached image.
I am trying to publish an upgrade of a Service Fabric application from Visual Studio 2017 to our Azure Service Fabric Cluster. In mid-September, I successfully published an upgrade of this same app with same PowerShell script to SFC with no issues. I am now trying to upgrade it at the next version number and suddenly getting this error.
I get the following error during Publish, related to Powershell.
2>Started executing script 'Deploy-FabricApplication.ps1'.
2>powershell -NonInteractive -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -Command ". 'C:\Users\pj\Source\Workspaces\VDevelopment\trunk\Services\Sources\src\For.Application.ServiceFabric.Sources\Scripts\Deploy-FabricApplication.ps1' -ApplicationPackagePath 'C:\Users\pj\Source\Workspaces\VDevelopment\trunk\Services\Sources\src\For.Application.ServiceFabric.Sources\pkg\Debug' -PublishProfileFile 'C:\Users\pj\Source\Workspaces\VDevelopment\trunk\Services\Sources\src\For.Application.ServiceFabric.Sources\PublishProfiles\Cloud.xml' -DeployOnly:$false -ApplicationParameter:#{} -UnregisterUnusedApplicationVersionsAfterUpgrade $false -OverrideUpgradeBehavior 'None' -OverwriteBehavior 'SameAppTypeAndVersion' -SkipPackageValidation:$false -ErrorAction Stop"
2>Copying application package to image store...
2>Upload to Image Store succeeded
2>Registering application type...
2>Register application type started. Use Get-ServiceFabricApplicationType to query for status.
2>Running Image Builder process ...
2>Application package is registered.
2>Start upgrading application...
2>aka.ms/upgrade-defaultservices
2>Start-ServiceFabricApplicationUpgrade : aka.ms/upgrade-defaultservices
2>At C:\Program Files\Microsoft SDKs\Service
2>Fabric\Tools\PSModule\ServiceFabricSDK\Publish-UpgradedServiceFabricApplication.ps1:317 char:13
2>+ Start-ServiceFabricApplicationUpgrade #UpgradeParameters
2>+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2> + CategoryInfo : InvalidOperation: (Microsoft.Servi...usterConnection:ClusterConnection) [Start-ServiceFa
2> bricApplicationUpgrade], FabricException
2> + FullyQualifiedErrorId : UpgradeApplicationErrorId,Microsoft.ServiceFabric.Powershell.StartApplicationUpgrade
2>
2>Finished executing script 'Deploy-FabricApplication.ps1'.
2>Time elapsed: 00:07:39.0407526
2>The PowerShell script failed to execute.
========== Build: 1 succeeded, 0 failed, 10 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========
Any idea what's going on here? Again, when I last published this in September, with the same script, no issues at all, and I haven't made any changes to the solution other than upgrading the Manifest versions to push it out as a new upgraded version.
I noted this S/O thread: Getting error as part of trying to upgrade Service Fabric Application using Start-ServiceFabricApplicationUpgrade and saw the user's error was similar, but the answer does not apply to my issue because all three steps in the answer provided are definitely included in my powershell deploy script.
I can add the deployment script if helpful, but will wait until that is requested as it's long, and I only want to post it here if someone feels it's needed to diagnose.
You are getting this error because you are changing some parameters in a DefaultService that are not allowed by default.
The link aka.ms/upgrade-defaultservices shown in the error logs explain this.
Some default service parameters defined in the application manifest
can also be upgraded as part of an application upgrade.
Only the service parameters that support being changed through
Update-ServiceFabricService can be changed as part of an upgrade. The
behavior of changing default services during application upgrade is as
follows:
Default services in the new application manifest that do not already exist in the cluster are created.
Default services that exist in both the previous and new application manifests are updated. The parameters of the default
service in the new application manifest overwrite the parameters of
the existing service. The application upgrade will rollback
automatically if updating a default service fails.
Default services that do not exist in the new application manifest are deleted if they exist in the cluster. Note that deleting a default
service will result in deleting all that service's state and cannot be
undone.
Also, there is this other SO question about the same thing: Default service descriptions can not be modified as part of upgrade set EnableDefaultServicesUpgrade to true
The item 1 above is a common approach, where new services are added to the solution and later created during the upgrade without errors, the item 2 and 3 are the restricted approach that requires the EnableDefaultServicesUpgrade.
The item 2, is like described in the answer you've added, you changed MinReplicaSize and TargetReplicaSize to 1 during a manual update, when SF validated the state of your service for upgrade, it identified the difference and prevented the upgrade to continue, if you had set cluster setting EnableDefaultServicesUpgrade to true it would continue and override the default values.
The item 3, would occur you when you removed the service and added again, you had changed or misspelled the name, SF default settings would prevent the deletion of this service.
Regarding the solution you've found(delete and recreate), is not ideal,
In scenarios where you have stateful services running in production, would be risky to apply, because you would have to backup the state, re-deploy the services, and restore the backup, in some cases, depending on what these changes are, you wouldn't be able to restore the backup, because they have to match with the original services definitions (partitions type, number, and son on). You would also lose the benefits of Rolling Updates, and your service would go down maybe for a while if these backups are big.
The issue had to do with us trying to push out the application with mismatched node instances. We have a stateful service running under this application that is supposed to have MinReplicaSize and TargetReplicaSize set to 3. Yesterday, due to an issue, we deleted and re-created this service inside the SF Explorer. Upon doing so, it reset the replica size parameters back to 1. So we used a Powershell script to change them back to 3, but that script did not include all the necessary commands to get the service back to the exact state it was in before we deleted it. So today when we went to upgrade the app, the app in SFC wouldn't accept an upgrade from VS deployment, because of mismatches between what was in the parameters of the solution vs. what was in our SFC. To resolve, we re-deleted those services first, then deployed from VS, and no more error.
I'm trying to create a pre-build step with powershell in one of our team projects to increment the build number for all assemblies/applications within that VS solution. This is for TFS2015-update 2.
I found some example code here and there online and have pieced together what I imagine would work. I can run the powershell script manually on the TFS server (authenticated to the server as my windows account) and it works fine, but yet it won't function correctly within the build process.
Here is the sample code in question where I keep getting my error. It has to do with authentication/connection to the TFS server:
$CollectionUrl=New-Object System.Uri("$env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI")
$BuildUrl="$env:BUILD_BUILDURI"
# get the team project collection
$TeamProjectCollection=[Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($CollectionUrl)
# get the build server
$BuildServer=$TeamProjectCollection.GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer])
# get the build detail
$BuildDetail=$BuildServer.GetBuild($BuildUrl)
# get the build definition
$BuildDefinition=$BuildDetail.BuildDefinition
There error I am getting is:
Exception calling "GetService" with "1" argument(s): "TF30063: You are not authorized to access http://servername/TPCName
I have tried using both the call above to get the TPC, and the constructer for it and neither works.
$TeamProjectCollection=New-Object Microsoft.TeamFoundation.Client.TfsTeamProjectCollection($CollectionUrl)
So I started trying to build a credential object based on my login credentials to the server and see if I could connect to the TPC that way. Still doesn't work (on server or in build process), but different error:
$netCred = New-Object System.Net.NetworkCredential($username,$password)
$basicCred = New-Object Microsoft.TeamFoundation.Client.BasicAuthCredential($netCred)
$tfsCred = New-Object Microsoft.TeamFoundation.Client.TfsClientCredentials($basicCred)
# get the team project collection
$TeamProjectCollection=New-Object Microsoft.TeamFoundation.Client.TfsTeamProjectCollection($CollectionUrl, $tfsCred)
Throws the exception:
Exception calling "GetService" with "1" argument(s): "TF400324: Team Foundation services are not available from the server.
I have also tried my best at modifying TFS permissions for the windows account that TFS service runs as to make sure there were no issues there. I'm fairly certain I added it to all roles/groups that my identity was in, but still the build wouldn't authenticate.
I'm at a loss at this point. Can someone help me figure out how to connect to the TFS server correctly using defined credentials, or help me adjust what permissions the service account, identity, configuration choices, etc; needed to access the teamProjectCollection.
You need to specifically instruct TFS/VSTS to allow the executing build to call back to TFS/VSTS. This protects your server for malicious developers exiting build scripts.
You should see an "enable Auth" option in the Options Tab of your Build.
**note: You should use the Task SDK provided: https://github.com/Microsoft/vsts-task-lib