I want to start working with Azure Service Fabric technology.
I am working according to this document and install the latest SDK.
After installation, I opened the PowerShell ("Run as administrator") command line windows and write those lines:
# Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope CurrentUser
# cd "$env:ProgramW6432\Microsoft SDKs\Service Fabric\ClusterSetup"
# .\DevClusterSetup.ps1
As an answer, got this error:
Cleaning existing cluster ...
NOTE: If this powershell command window exits, please re-run the script in a new powershell command window.
Stopping service FabricHostSvc. This may take a few minutes...
Removing cluster configuration
Remove node configuration succeeded
Cleaning existing certificates
Stopping all logman sessions
Cleaning log and data folder, the powershell window may close automatically.
ClusterPath not provided, will use C:\SfDevCluster
FabricDataRoot not provided, will use C:\SfDevCluster\Data
FabricLogRoot not provided, will use C:\SfDevCluster\Log
Directory: C:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 4/11/2015 12:47 PM SfDevCluster
Directory: C:\SfDevCluster
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 4/11/2015 12:47 PM Manifests
True
Create node configuration succeeded
Starting service FabricHostSvc. This may take a few minutes...
Start-Service : Failed to start service 'Microsoft Service Fabric Host Service (FabricHostSvc)'.
At C:\Program Files\Microsoft SDKs\Service Fabric\ClusterSetup\DevClusterSetup.ps1:167 char:1
+ Start-Service FabricHostSvc -WarningAction SilentlyContinue
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service],
ServiceCommandException
+ FullyQualifiedErrorId : StartServiceFailed,Microsoft.PowerShell.Commands.StartServiceCommand
WARNING: Could not start FabricHostSvc
The bottom line is "Failed to start service". This output is printed to the screen after 3 minutes of waiting.
Things I've already been tried:
Restart the computer few times (I was reading somewhere that this solve the problem).
Turn OFF my Anti-virus\firewall software.
Attached screenshot of the PowerShell Command line.
I'm using:
Visual studio 2015 Enterprise edition
Windows 8.1
Azure Service Fabric SDK v1.0.328
I also fought with this problem just this morning. I did NOT have to reinstall Windows.
I too found events in the event log talking about corrupt performance counters. I'm not sure if it's related or not but I ran this command from a cmd windows as administrator to rebuild the performance counters and the error clear up:
lodctr /r
I then went to Programs and Features and uninstalled anything that mentioned Service Fabric.
I then reinstalled the Service Fabric SDK and followed the instrucions on the Azure Service Fabric environment setup page here and my cluster started working fine.
I was facing the same issue and tried many times one evening and next morning I got the answer. Well the answer is "Ensure that Firewall is on".
UPDATE2: This is a very old issue and I have not seen this reoccur since Nov 2015. (added just so this post doesn't get down-voted any more :-/ ).
UPDATE: I have not had this issue since the November update.
ORIGINAL:I had this issue the other day and tried everything. I had uninstalled, rebooted, reinstalled everything from Service Fabric down to Azure SDK's and Visual Studio.
The fix - pretty bad. Reinstall windows.
At one point, I found a trace that indicated a registry corruption. Something about unable to find a performance counter.
Right now I have a new issue (which I'll post separately) but just repeating here to let people know there is some buggy infrastructure under this service right now.... My stateful/stateless app deploys. The stateless app deploys and runs. The stateful service deploys but will not replicate. If I run exactly the same code on another machine (and I mean copy/paste to other machine then run it), it all works.
Related
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've been trying to install and start the new preview SDK, and even after several installs/uninstalls/reboots I always get this error when running DevClusterSetup:
Start-Service : Failed to start service 'Microsoft Service Fabric Host Service (FabricHostSvc)'.
At C:\Program Files\Microsoft SDKs\Service Fabric\Tools\Scripts\ClusterSetupUtilities.psm1:433 char:5
(full log below)
What I've tried, from other posts on stackoverflow:
reparing the performance counters with lodctr /R
used the system file checker with SFC /SCANNOW
checked that the windows firewall is running (and tried disabling it for the domain networks)
made sure I have enough disk space
The windows service "Microsoft Service Fabric Host Service" is always "Starting", but never starts.
I have two hints as to what the source of the problem might be, but can't solve it:
a) in the event viewer (Microsoft-Service Fabric > Admin) there are 4 errors that occur everytime the service attempts to start:
Unable to stop data collector for performance counters. The command
"logman stop FabricCounters" failed with error code -2147287038.
System.Fabric.FabricDeployer.InvalidDeploymentException: Failed to
start performance counter collection when creating or updating
deployment
FabricDeployer::Install failed with error 0xffffffff
FabricDeployer::Install failed with error 0xffffffff, Rolling back
b) In the C:\SfDevCluster\Log\Traces folder there are files named something like FabricSetup-131034051696570691.trace . All of them have the same content, and in the middle there are warnings like these:
FabricSetup.FabricSetup.EventTraceInstaller,Method QueryDataCollectorSet failed with HRESULT: -2144337918
FabricSetup.FabricSetup.EventTraceInstaller,Method StopPlaTraceSession failed with HRESULT: -2144337918
and then further down the error:
FabricSetup.FabricSetup.FabricDeployer,Configuration Deployment failed with error 0xffffffff
If I go and check the Fabric deployer files (eg, fabricdeployer-635945286697202537.trace), I have a single error at the end, after a series of Performance counter deletes:
FabricDeployer.FabricDeployer,Executing command: logman stop FabricCounters
FabricDeployer.FabricDeployer,Unable to stop data collector for performance counters. The command "logman stop FabricCounters" failed with error code -2147287038.
but this error seems to come after some other error, as part of the rollback.
Any ideas? This is very frustrating and there is very little info on the net.
I've also tried cleaning the installation with ClearCluster.ps1 and installing the dev cluster to a different folder, always with the same result.
I am running Win10 with VS2015 Update 1, Azure SDK 2.8.2.1 . My user is a liveid which is local admin.
I'll start with a short answer to unblock you. From an elevated powershell session run:
Unregister-ScheduledTask FabricCounters
I had the exact same issue but in my case the FabricCounters task wasn't there. So I did a search for other "Fabric*" tasks via Get-ScheduledTask Fabric* and found both FabricAppInfoTraces and FabricQueryTraces to be present still after uninstall.
I removed both Tasks using Unregister-ScheduledTask <name>, reinstalled the SDK and was able to start my local cluster again!
EDIT: I overlooked "Prerequisites for executing build definitions is to have your build agent ready, here are steps to setup your build agent, you can find more details in this blog ." from these steps. I'm currently trying to get that build agent up and running on an Azure VM and will report back.
I'm following these steps to try and get CD and Selenium tests running through my Visual Studio Online TFbuild. I've had some helpful hints after sending some feedback via email, but I'm still not able to get past the file copy step.
I've created a Windows 10 Enterprise VM.
I've correctly set the ip address in my build test machines and am able to RDP into the machine.
I've successfully (after several attempts) gotten Remote Power shell working (though I'm not 100% certain winrm s winrm/config/client '#{TrustedHosts="Hosted Agent"}'). I got the name from https://{}.visualstudio.com/DefaultCollection/_admin/_AgentQueue or Build > edit build > General > Default Queue > Manage.
PS C:\users\cdd\Desktop> winrm quickconfig
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
This seems to be ready after
PS remoting is not supported when network connection type is public. Please check http://blogs.msdn.com/b/powershell/archive/2009/04/03/setting-network-location-to-private.aspx.
and echo "setting executionpolicy"
powershell -command "& Set-ExecutionPolicy -executionpolicy unrestricted -force"
echo "setting remoting"
powershell -command "& Enable-PSRemoting -force"
That's a lot of details, but I'm still stuck after that:
Copy started for - '{ip}:5985'
Copy status for machine '{ip}:5985' : 'Failed'
Failed to execute the powershell script. Consult the logs below for details of the error.
Failed to connect to the path \{ip} with the user cdd for copying.System error 53 has occurred.
The network path was not found.
For more info please refer to http://aka.ms/windowsfilecopyreadme
I have a few questions:
Do I have the correct name of the VM?
Do you have steps on how to get the VM setup to allow FileCopy?
I'm probably missing something else, I'm not familiar with PowerShell or getting this setup. What can I try to get the path available for my cdd adminstration user that I setup when I created the VM?
To copy files to an Azure VM machine, you should use the "Azure File Copy" step that provided in VSO build definition. It provides detailed setting for you to access to your Azure VM machine.
I was given the task of removing bloatware from a brand-new Acer laptop. My (and the laptop owner's) definition of bloatware includes all pre-installed Apps and the Winstore itself. You may disagree with that, but that's beside the point.
I tried the remove-appxpackage Powershell command with Winstore's ID and got an error, the important part of which is
This app is part of Windows and cannot be uninstalled on a per-user basis. An
administrator can attempt to remove the app from the computer using Turn Windows Features on or off. However, it may not be possible to uninstall the app.
I didn't see any such option in the Windows Features menu. Can the Winstore be removed from Win8.1?
Here's the full error message (for reference):
remove-appxpackage : Deployment failed with HRESULT: 0x80073CFA, Removal failed. Please contact your software vendor.
(Exception from HRESULT: 0x80073CFA)
error 0x80070032: AppX Deployment Remove operation on package winstore_1.0.0.0_neutral_neutral_cw5n1h2txyewy from:
C:\Windows\WinStore failed. This app is part of Windows and cannot be uninstalled on a per-user basis. An
administrator can attempt to remove the app from the computer using Turn Windows Features on or off. However, it may
not be possible to uninstall the app.
NOTE: For additional information, look for [ActivityId] 83cee5eb-80ef-0001-3bc1-cf83ef80d001 in the Event Log or use
the command line Get-AppxLog -ActivityID 83cee5eb-80ef-0001-3bc1-cf83ef80d001
At line:1 char:1
+ remove-appxpackage winstore_1.0.0.0_neutral_neutral_cw5n1h2txyewy -confirm
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : WriteError: (winstore_1.0.0....l_cw5n1h2txyewy:String) [Remove-AppxPackage], IOException
+ FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.RemoveAppxPackageCommand
I am sure you figured this out by now, but seeing as you haven't given this question an check mark for correct answer I am giving you my two cents.
First stop the service named:
Go to Services
Find the service called: Display Name: Windows Store Service(WSService)
Run "remove-appxpackage Winstore's ID"
This should remove the application, but only once the service is stopped. If you cannot find the service in Services, go find it in the registry. The registry name is: Service Name (registry): WSService
Let me know if this helps you a year and a half later. For future reference all applications running a services most likely need that service stopped before a remove is possible.
The UnderDog
You should be able to remove the Winstore in the context of the machine, rather than the user (which is implied by the error message). I have met with success removing Group Policy (which also insists that it is a part of Windows) by using a Task Scheduler task (running as LOCALSYSTEM) to stop the service and then remove it.
Since the Winstore is a Windows Service, this solution should work for you.
I've recently upgraded a number of servers from 2003 to 2008R2. Since the upgrade I've started to see the following error:
[servername] Connecting to remote server failed with the following error message : The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic.
The error is seemingly random. The script will work and then fail. The command to create the session is in a loop (create session, remove session) and is called numerous times as part of a set of deployment scripts. When the script fails, it fails at different points.
I've checked the event log on the local workstation (win7) destination server (win2008R2) but there are no errors that I can see.
This is the lines that randomly fails:
$session = New-PSSession -ComputerName $serverName -Credential $credential
I did not see this issue on Win2003. The scripts have not changed. I'm assuming the problem is on the destination server but cannot find any errors or logs to look at. It will work once and then fail so my deployment scripts will sometimes succeed and then fail at different points.
Any guidance on tracking down this problem would be much appreciated.
You can get this error when trying to connect to localhost with an account that's not an administrator.
It used to be possible to use accounts that weren't an administrator, but a Windows Update in January 2019 disabled the functionality for security reasons. From the patch notes:
By default, PowerShell remoting only works with administrator accounts, but can be configured to work with non-administrator accounts. Starting with this release, you cannot configure PowerShell remote endpoints to work with non-administrator accounts. When attempting to use a non-administrator account, the following error will appear:“New-PSSession: [computerName] Connecting to remote server localhost failed with the following error message: The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic.”
You need to be setting the WSMan TrustedHosts. If you want, you can set it to everything using wildcards (*).
You can do it via PowerShell: Set-Item WSMan:\localhost\Client\TrustedHosts -Value *.
Keep in mind that you also need to enable the Windows Remote service. Use the native winrm qc command for this. Enable-PSRemoting -Force might do it as well.
You can also use the PSExec Tools from Sysinternals. Keep in mind that these tools will likely be blocked by your EndPoint Security, so don't forget to white list it.
Is there a specific reason you migrate your old OSes to a newer, but still EOL OS? You can do a lot via PowerShell in 2008R2, but it's still pretty limited. IMO, Using PowerShell is best starting from 2012R2 and onwards.
Are you hitting the number of processes limit by creating pssessions that are crashing and leaving processes open?
Default limit is 15. I'd agree with the above comment and not use sessions, instead use invoke-command like:
invoke-command -scriptblock $scriptBlock -ArgumentList $args -computername $compName -Credential $encodedRemoteCredentials
to Check your limit:
PS C:\aws> ls WSMan:\localhost\Shell
WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Shell
Name Value
---- ----
MaxProcessesPerShell 15
As a quick and dirty test - next time your pssession version of your script fails, increase the maxProcessesPerShell limit using set-item cmdlet to 50 and retry. If the script no longer fails, you know that's the issue (and should consider moving to invoke-command!).