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.
Related
I want to run a deployment groups on my virtual machine.
I have run my registration script (PowerShell), but it shows the error:
Exception calling "DownloadFile" with "2" argument(s): "The remote name could not be resolved:
'vstsagentpackage.azureedge.net'"
At line:1 char:1303
+ ... nalString, $True);}; $WebClient.DownloadFile($Uri, $agentZip);Add-Typ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : WebException
I found in Microsoft document that I need to pass --proxyurl, --proxyusername and --proxypassword in the script.
./config.cmd --proxyurl http://127.0.0.1:8888 --proxyusername "myuser" --proxypassword "mypass"
But I don't know what value to fill in, especially the URL.
I tried to copy this script and put it in my registration script, but the same error still occurs.
Any help would be appreciated.
I think if you are using this on your office network or wherever the internet connection requires proxy, and that may have proxy settings, then you can get the proxy url from the Internet proxy settings. Creds has to be supplied if it uses a proxy username/pwd.
The below info may not be ideal for everyone, so don't blame me for this solution but this is what worked for me and for my need.
Note: THIS HAS TO HAVE ATTENTION AND UTMOST CARE IF YOU'RE RUNNING ON A SERVER
you may copy the ps scripts to a notepad,
do the steps manually on the designated server.
Download the agent zip file from web
extract it
copy the contents to the A# folder that you want to setup, mostly A1
run the config.cmd line from the ps script which would expect the appropriate creds that you need to make sure to supply as token
If you have appropriate permissions, it will go forward and install the agent on the respective server and prompt you for further steps like tags etc.
UPDATE:
I didn't have enough permissions to create the Deployment group but rather, just a deployment item (VM)
So I created the Deployment group manually from the deployment target. I had issues when creating it but going backwards by creating a group from the target was successful for me.
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 am working on making some scripts to make my job a little bit easier.
One of the things i need is too download some files to use. I first used powershell with the command Invoke-WebRequest.
It is working really well, however it dont run on windows 7 computeres, as they have powershell 2. As i have about as many windows 7 pc's as win 10 i need to find another way.
I found that Start-BitsTransfer is a good way that should work on most computeres. My problem now is, that when using the script via my remote support session it runs the script on the local service account, and then BitsTransfer wont run and gives me an error. (0x800704DD)
Is there a way to get around that problem, or any command that can be used on both win 7 and 10 and run from the local service account?
You should update PowerShell as gms0ulman states, but if you are not the person who is in charge of this decision, you have to take other steps.
This error code...
0x800704DD
The error message ERROR_NOT_LOGGED_ON, occurs because the System Event Notification Service (SENS) is not receiving user logon notifications. BITS (version 2.0 and up) depends on logon notifications from Service Control Manager, which in turn depends on the SENS service. Ensure that the SENS service is started and running correctly.
By default, BITS runs under the LocalSystem account. To modify, stop or restart BITS, you must be logged on as an administrator. In your situation, when you log on a regular account and start the PS in elevated privilege, the BITS doesn’t run under regular user account. To resolve it, you may need to configure the log on user for BITS. Please visit the following link to configure how a service is started.
Configure How a Service is Started
Services are often run with default settings — for example, a service
may be disabled automatically at startup. However, you can use the
Services snap-in to change the default settings for a service. This is
useful if you are troubleshooting service failures or if you need to
change the security account under which a service runs. Membership in
Account Operators or Domain Admins, Enterprise Admins, or equivalent,
is the minimum required to complete this procedure. Review the details
in "Additional considerations" in this topic.
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc755249(v=ws.10)
I also agree that you should not continue supporting PowerShell 2.0. Ideally, ditch Windows 7 (it's way too old now), if you can't do that, upgrade PowerShell, if you can't do that, find a new job, if you can't do that, then I guess bring on the workarounds!
postanote's answer covers the BITS angle.
The other thing you can do is just use the .Net framework's underlying libraries, which is exactly what Invoke-RestMethod and Invoke-WebRequest do (those cmdlets were introduced in PowerShell 3.0, but the guts of them were around much longer).
try {
$wc = New-Object -TypeName System.Net.WebClient
$wc.DownloadFile($url, $path)
finally {
$wc.Dispose()
}
Most people don't bother disposing IDisposable objects in PowerShell so you'll see a lot of shorthand around like this:
(New-Object Net.WebClient).DownloadFile($url, $path)
Which is probably fine if your script's process isn't going to be around for a while, but it's good to keep in mind in case you incorporate this into something of a larger scale.
When trying to set up the local cluster the powershell script I get the following error:
Is there any way of continuing the installation or fixing the cause of this error?
Cheers,
Mike
I have completely removed the SDK and started over but I am still having the same issues. Everything boils down to the 'Connect-ServiceFabricCluster' just doesn't work at all (I have followed all of the suggestions provided).
Surely the warnings about the naming services must point to something?
Each attempt I see the following:
WARNING: Failed to contact Naming Service. Attempting to contact Failover Manager Service...
2>WARNING: Failed to connect Failover Manager Service, Attempting to contact FMM...
2>Connect-ServiceFabricCluster : A communication error caused the operation to fail.
2>At D:\Source\Play\ServiceFabricApplication\ServiceFabricApplication\Scripts\Deploy-FabricApplication.ps1:158 char:16
2>+ ... [void](Connect-ServiceFabricCluster #ClusterConnectionParameters ...
2>+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2> + CategoryInfo : InvalidOperation: (:) [Connect-ServiceFabricCluster], FabricTransientException
2> + FullyQualifiedErrorId : CreateClusterConnectionErrorId,Microsoft.ServiceFabric.Powershell.ConnectCluster
Attempting a reset from the tray:
Tray output
In my case the Cluster was not running (ie no Fabric.exe processes in Task Manager).
I was able to get things working again my opening a Powershell as Admin and running:
& "$ENV:ProgramFiles\Microsoft SDKs\Service Fabric\ClusterSetup\DevClusterSetup.ps1"
After that close the powershell window and open a new one (as Admin). Then Connect-ServiceFabricCluster worked.
This usually indicates that the main service host isn't running. If this is on our just-released public preview SDK, you can usually resolve these situations by resetting the cluster (just right click on the service fabric tray icon and click reset). If this is an older rev, well, then first you should upgrade :) But other than that you can check inside services.msc and make sure FabricHostSvc is running.
The error is a temporary communication error. Open Task Manager, go to 'Details' tab and check if 'FabricHost.exe' and 'Fabric.exe' is running. This indicates if the cluster has been setup and running.
Open a new administrator PowerShell window and try to connect to cluster using 'Connect-ServiceFabricCluster'.
If the connection still fails, try to remove the cluster using 'CleanCluster.ps1' and setup it again using 'DevClusterSetup.ps1'. This should fix the issue.
Please visit Troubleshoot your local development cluster setup.
I recently had a similar situation where all the TCP connections were erroring out with a FabricTransientException exception.
The underlying cause turned out to be the Windows Firewall. Once I disabled the firewall for the domain network, the connections were successful and the services were again accessible.
P.S> In case someone faces the same issue: Initially the problem was that after the installation Fabric Host service was just stalling with the "Starting" status. Main cause for this problem was that Windows Firewall service was disabled on the server. After enabling and starting the windows service, the Fabric Host service started as expected.
I am trying to uninstall a recently installed service, I am running this in command line:
c:\Windows\Microsoft.NET\Framework\v4.0.30319>installutil.exe /u "C:\inetpub\www
root\xxx\xxx\xxx.exe"
But I am getting this:
The uninstall has completed.
An exception occurred while uninstalling. This exception will be ignored and the
uninstall will continue. However, the application might not be fully uninstalle
d after the uninstall is complete.
And this:
Removing EventLog source xxx.
An exception occurred during the uninstallation of the System.Diagnostics.EventL
ogInstaller installer.
System.Security.SecurityException: Requested registry access is not allowed.
An exception occurred while uninstalling. This exception will be ignored and the
uninstall will continue. However, the application might not be fully uninstalle
d after the uninstall is complete.
I have no idea where to begin and I really need to uninstall these so any help is appreciated
I was facing exact same issue.
The issue is resolved by opening the Command Prompt as Administrator.
My guess is that you are probably trying to remove a service using a user account which does not have sufficient rights. Specifically, the issue in this case is the removal of some EventLog registry keys during Uninstall.
This may also occur when you are logged in as a user with Administrator privileges yet did not run the Command Prompt in 'Administrator Mode'.
One way to fix this is to make sure that you are running the Command Prompt in Administrator mode. (Right-click > Run as Administrator)
I have also encountered some cases where this method still fails to solve the SecurityException problem due to some registry keys not having 'Full Control' permissions for Administrator accounts.
The following keys should have 'Full Control' set for Administrators in order for the service to be able to write to the EventLog:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application
This may be done by:
Invoking the Windows Registry Editor
Run [Win + R]
Type 'regedit'
OK
Navigate a path listed about
Right click on the desired path
Make sure that both Read and Full Control permission checkboxes are ticked for Administrators
Click Apply and OK
Repeat the same process for the other path