Force delete of Service Fabric application - azure-service-fabric

I am having issues during development where an exception during service start up causes the application to get stuck in an error state. This prevents further debugging. I can't seem to delete the application through the cluster management portal either, it just times out.
The only way I've found to fix is to reset the cluster, which takes a few minutes and deletes all other applications from the cluster as well.
What's the correct way to force delete of an individual application?

I created the following powershell script which seems to do the trick:
param([string]$applicationName = "SomeAppName", [string]$version = "1.0.0")
$applicationUri = "fabric:/" + $applicationName
$applicationTypeName = $applicationName + "Type"
Connect-ServiceFabricCluster localhost:19000
Write-Host ""
Write-Host "Removing $applicationUri from local cluster"
Remove-ServiceFabricApplication -ApplicationName fabric:/$applicationName
Write-Host ""
Write-Host "Removing $applicationTypeName (v$version) from local cluster"
Unregister-ServiceFabricApplicationType -ApplicationTypeName $applicationTypeName -ApplicationTypeVersion $version
Write-Host ""
Write-Host "Complete"
Can be called like so:
.\Delete-SF-App.ps1 -applicationName "MyService" -version "1.0.0"
EDIT:
If the above doesn't work then the below powershell command can be used to remove individual replicas:
$nodes = Get-ServiceFabricNode
foreach($node in $nodes)
{
$replicas = Get-ServiceFabricDeployedReplica -NodeName $node.NodeName -ApplicationName $applicationName
foreach ($replica in $replicas)
{
Remove-ServiceFabricReplica -ForceRemove -NodeName $node.NodeName -PartitionId $replica.Partitionid -ReplicaOrInstanceId $replica.ReplicaOrInstanceId
}
}

Please ignore this answer if you aren't using Visual Studio for development and debugging.
I know the question is already answered but have you tried to change Application Debug Mode setting in Visual Studio to Remove Application?

Related

Provider cannot be found when try to open/access mdb

I'm writing a powershell 5.1 script to query info from a mdb file based on this article. I get this error message when I try to open/access an mdb file:
MDB Open next
Provider cannot be found. It may not be properly installed.
I'm pretty sure I need to adjust my connection info according to what I have installed. This is what I'm doing:
$pathViewBase = 'C:\Data\EndToEnd_view\' #View dir.
$XML_MDB_Dirs = #('\AppText.mdb') #more files later
foreach($mdbFile in $XML_MDB_Dirs)
{
$pathToMdb = Join-Path -Path $pathViewBase -ChildPath $mdbFile
if(Test-Path $pathToMdb)
{
$cn = new-object -comobject ADODB.Connection
$rs = new-object -comobject ADODB.Recordset
Write-Host "MDB Open next" -ForegroundColor DarkCyan
$cn.Open("Provider = Microsoft.Jet.OLEDB.4.0;Data Source = $pathToMdb") ###error this line
Write-Host "Open done" -ForegroundColor DarkCyan
$rs.Open(“SELECT TOP 1 [TableName].[Message Description],
[TableName].[Column1]
FROM [TableName]
WHERE [TableName].[Message Description] = 'ERROR'”,
$cn, $adOpenStatic, $adLockOptimistic)
$rs.MoveFirst()
Write-Host "Message value obtained for ERROR: " $rs.Fields.Item("Name").Value
Break ##########################
}#test-Path
}#foreach
I found this regarding odbc connections, and it seems to say I need to adjust my connection info. Looking at what's installed on my computer, I see this, but I'm a little unclear what I need to adjust my open code to use. Would I need to replace 'Microsoft.Jet.OLEDB.4.0' with 'SQLNCLI11.dll'?
Update:
I checked,
(Get-WmiObject Win32_OperatingSystem).OSArchitecture
and I am running 64 bit powershell, so since I installed accessdatabaseengine_x64.exe access database engine, per #
Mathias R. Jessen below (and rebooted), that's correct. But I still get the same error. I'm not sure if there's something I could check to see if it's installed correctly, or if I need to use SQLNCLI11.0 as the provider instead of Microsoft.Jet.OLEDB.4.0, or if I need to add "using" at the top? Or do I need to check if a powershell module is installed?

Service cannot be started due to the following error: Cannot open service on computer '.'

I'm trying to Start a service using Powershell and using the code below
function CheckServiceStatus {
param($winupdate)
$getservice = Get-Service -Name $winupdate
if($getservice.Status -ne $running){
stop-service $winupdate
Start-Service $winupdate
Write-output "Starting" $winupdate "service"|out-file "C:\Users\Mani\Desktop\abc.txt"
Add-Content C:\Users\Mani\Desktop\abc.txt $getservice.Status
}
}
Read-Host -Prompt "Press Enter to exit"
#Variables
$winupdate = 'vsoagent.192.Shalem'
$running = 'Running'
CheckServiceStatus $winupdate
I got the following error:
Service 'ABC' cannot be stopped due to the following error: Cannot
open ABC service on computer '.'
I found some link here on our forum but couldn't resolve. Please suggest
If you want to start/stop/etc services, you need elevated privileges (run as Admin). You can still get information about the service, but that's it. If you want to include a more verbose error, include this:
$isadmin = [bool](([System.Security.Principal.WindowsIdentity]::GetCurrent()).groups -match "S-1-5-32-544")
if($isadmin){
Write-Error "You need elevated privileges to run this script"
exit(1)
}
...
Rest of your code
Or even better, if you're running Powershell 4.0 or higher (You can get it by checking $PSVersionTable), you can include
#Requires -RunAsAdministrator
At the top of your file, and you won't be able to run it without admin privilages.
I had this issue while running the command on PowerShell ISE. All I did was start the PowerShell ISE as an administrator.
Look into Event Viewer and find more details. In my case, I have found relevant info in Administrative Events, then Service Control Manager. The error was related to insufficient privileges given for the account. The service was creating a new file and this task failed. Of course, your error's details are probabably different, but that is the tip.

Is it possible to turn the kubernetes feature on in docker-for-windows with automation?

I am working on an ansible based dev-bootstrap project. I'd like to be able to enable the kubernetes from the docker role, but i cant seem to find a way to do so. I searched the registry for docker and kubernetes, nothing jumped out. I also checked for a daemon.json, but none is present even though i have kubernetes enabled (manually). Does anyone know if there is a way to make this happen?
Not sure if this is all you need, but when toggling the enable Kubernetes option it writes to the settings.json. There is also a Kubernetes Initial install step, so this might not be enough, but I would try see if it picks it up, needs a restart or doesn't work at all...
function Enable-DockerKubernetes {
[CmdletBinding()]
param ()
try {
$settings = "$env:AppData\Docker\settings.json"
$dockerSettings = ConvertFrom-Json ( Get-Content $settings -Raw -ErrorAction Stop)
if (!$dockerSettings.KubernetesEnabled) {
Write-Verbose ("Enabling Kubernetes in {0}." -f $settings)
$dockerSettings.KubernetesEnabled = $true
$dockerSettings | ConvertTo-Json | Set-Content $settings -ErrorAction Stop
}
else {
Write-Verbose "Already enabled!"
}
}
catch {
Write-Error $_
}
}
The installer for Docker CE doesn't seem to support passing in installer options according to this issue which just went stale and got closed.
You might want to open a new issue specifically about this use case.
https://github.com/docker/for-win/issues/1322

Install Windows HotFix using Terraform on AWS

I have a very simple PowerShell script that uploads a generated test file to an AWS S3 bucket from a Windows 2008 R2 Datacenter server (clean AWS instance). If I run the script remotely on the server using Terraform (remote-exec provisioner), the script fails on the S3 upload with a StackOverflowException. When I run the script directly on the server, it runs fine and uploads the file.
I've experimented with different sizes for the file and 14.5MB seems to be about the maximum that works before the StackOverflowException occurs. Just about any size works fine when I RDP into the server and run the script directly. I've tested 200MB and it works fine.
Any idea why this is happening or what I can do to fix it? The actual file I need to upload is 50MB.
Here are the essential parts to recreate the problem. terraform.tf file:
resource "aws_instance" "windows" {
count = "1"
ami = "ami-e935fc94" #base win 2008 R2 datacenter
instance_type = "t2.micro"
connection {
type = "winrm"
user = "<username>"
password = "<password>"
timeout = "30m"
}
provisioner "file" {
source = "windows/upload.ps1"
destination = "C:\\scripts\\upload.ps1"
}
provisioner "remote-exec" {
inline = [
"powershell.exe -File C:\\scripts\\upload.ps1"
]
}
}
The PowerShell script is very simple. upload.ps1:
$f = new-object System.IO.FileStream C:\Temp\test.dat, Create, ReadWrite
$f.SetLength(40MB) # change this to 14.5MB and it works!
$f.Close()
Write-S3Object -BucketName "mybucket" -Folder "C:\Temp" -KeyPrefix "20180322" -SearchPattern "*.dat"
The error that I receive when launching the script from Terraform (remote-exec provisioner):
aws_instance.windows (remote-exec): Process is terminated due to StackOverflowException.
Running upload.ps1 from RDP on the server itself works fine, including larger files (tested up to 200MB).
Here is the version information:
Microsoft Windows Server 2008 R2 Datacenter
Powershell Version: 3.0
AWS Tools for Windows PowerShell, Version 3.3.245.0
Amazon Web Services SDK for .NET, Core Runtime Version 3.3.21.15
This problem results from a Windows bug. This is all fine and good for a standard Windows server -- you can patch and move on. But, things are more tricky with AWS automation using Terraform.
The ideal solution would allow 1) use of the base AMI, 2) apply the hotfix to itself, and 3) then run the WinRM remote-exec, all from Terraform. Another solution would be to create an AMI with the hotfix installed and have Terraform generate instances using that AMI. However, then you're stuck maintaining AMIs.
Normally, I grab the Microsoft-provided base AMI using a filter:
data "aws_ami" "windows2008" {
most_recent = true
filter {
name = "virtualization-type"
values = ["hvm"]
}
filter {
name = "name"
values = ["Windows_Server-2008-R2_SP1-English-64Bit-Base*",]
}
owners = ["801119661308", "amazon"]
}
Then I use that AMI to create the AWS instance:
resource "aws_instance" "windows" {
count = "1"
ami = "${data.aws_ami.windows2008.id}"
...
}
But, the base AMI doesn't have the hotfix installed allowing you to avoid this WinRM/Windows bug. This is were it gets tricky.
You can use a userdata script to perform a multi-phase setup. In the first boot of the instance (Phase 1), we'll block the instance so that the remote-exec doesn't come in before we're ready. Then, we'll download and install the hotfix and we'll reboot (thanks to Niklas Akerlund, Micky Balladelli and Techibee). On the second boot (in method described here), we'll unblock the instance (enable WinRM) so that the remote-exec can connect.
Here's my userdata/PowerShell script:
$StateFile = "C:\Temp\userdata_state.txt"
If(-Not (Test-Path -Path $StateFile))
{
# PHASE 1
# Close the instance to WinRM connections until instance is ready (probably already closed, but just in case)
Start-Process -FilePath "winrm" -ArgumentList "set winrm/config/service/auth #{Basic=`"false`"}" -Wait
# Set the admin password for WinRM connections
$Admin = [adsi]("WinNT://./Administrator, user")
$Admin.psbase.invoke("SetPassword", "${tfi_rm_pass}")
# Create state file so after reboot it will know
New-Item -Path $StateFile -ItemType "file" -Force
# Make it so that userdata will run again after reboot
$EC2SettingsFile="C:\Program Files\Amazon\Ec2ConfigService\Settings\Config.xml"
$Xml = [xml](Get-Content $EC2SettingsFile)
$XmlElement = $Xml.get_DocumentElement()
$XmlElementToModify = $XmlElement.Plugins
Foreach ($Element in $XmlElementToModify.Plugin)
{
If ($Element.name -eq "Ec2HandleUserData")
{
$Element.State="Enabled"
}
}
$Xml.Save($EC2SettingsFile)
# Download and install hotfix
# Download self-extractor
$DownloadUrl = "https://hotfixv4.trafficmanager.net/Windows%207/Windows%20Server2008%20R2%20SP1/sp2/Fix467402/7600/free/463984_intl_x64_zip.exe"
$HotfixDir = "C:\hotfix"
$HotfixFile = "$HotfixDir\KB2842230.exe"
mkdir $HotfixDir
(New-Object System.Net.WebClient).DownloadFile($DownloadUrl, $HotfixFile)
# Extract self-extractor
Add-Type -AssemblyName System.IO.Compression.FileSystem
[System.IO.Compression.ZipFile]::ExtractToDirectory($HotfixFile, $HotfixDir)
# Install - NOTE: wusa returns immediately, before install completes, so you must check process to see when it finishes
Get-Item "$HotfixDir\*.msu" | Foreach { wusa ""$_.FullName /quiet /norestart"" ; While (#(Get-Process wusa -ErrorAction SilentlyContinue).Count -ne 0) { Start-Sleep 3 } }
# Reboot
Restart-Computer
}
Else
{
# PHASE 2
# Open WinRM for remote-exec
Start-Process -FilePath "winrm" -ArgumentList "quickconfig -q"
Start-Process -FilePath "winrm" -ArgumentList "set winrm/config/service #{AllowUnencrypted=`"true`"}" -Wait
Start-Process -FilePath "winrm" -ArgumentList "set winrm/config/service/auth #{Basic=`"true`"}" -Wait
Start-Process -FilePath "winrm" -ArgumentList "set winrm/config #{MaxTimeoutms=`"1900000`"}"
}

Trying to create process on remote PC from network share

I have this Powershell:
Try
{
#Start the installer remotely
$process = ([WMICLASS]"\\$comp\ROOT\CIMV2:Win32_Process").Create($InstallString)
if ( $process.ReturnValue -eq 0 )
{
$logstr = $comp + ": spawned process " + $process.ProcessId
Write-Host -ForegroundColor GREEN $logstr
}
else
{
Write-Host -ForegroundColor RED "${comp}: failed to create process ${InstallString}"
Continue
}
}
Catch
{
Write-Host -ForegroundColor RED "${comp}: error: $_.Exception.Message"
Continue
}
Where $comp is a valid PC name and InstallString is \\SERVERNAME\ShareFolder\setup.exe.
Within that ShareFolder is an installer and its files. I expect I can run the setup like this to remote install, but it is not working. It's falling into the else:
COMPUTERNAME: failed to create process \\SERVERNAME\ShareFolder\setup.exe
What am I missing? I can access this path outside Powershell.
This works on a local path. Do I need some special syntax in Powershell to point to this share?
This code works if the exe (well, a different installer) is located on COMPUTERNAME and the code is still executed remotely.
It could be a permission problem. According to this link: Creating Processes Remotely
A process created remotely can run under any account if the account has the Execute Method and Remote Enable permissions for root\cimv2. The Execute Method and Remote Enable permissions are set in WMI Control in the Control Panel.