Tag Archives: Windows

Repair Windows 10 Apps

At some point last year I had a problem with the Windows 10 Photo App not launching properly. In my attempts to repair it I ended up breaking all of the built-in Windows 10 Apps including the Store.

The Apps were now all in a state where they had no Icons, and their names were along the lines of “@Microsoft.WindowsStore….” and would not launch at all.

I attempted numerous fixes and read up many articles with suggested fixes to no avail including:

  • Running System File Checker “sfc /scannow” – no problems found
  • Attempting to reset the Windows store with “wsreset” – no change
  • Running DISM with the “/scanhealth”, “/checkhealth” and then “/restorehealth” flags – Fixed some problems though no change to the Windows Apps

You can re-install all of the Windows Apps using the following Powershell command, however beware, this is what caused my problems to begin with!

Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml”}

For me running this would spew out a bunch of errors similar to the following:

Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF6, Package could not be registered error 0x80070003: Reading manifest from location: AppxManifest.xml failed with error: The system cannot find the path specified.

You may notice in the error description the recommendation to check the Event Log or using the cmdlet “Get-AppxLog”. I ran the latter which gave me the following output:

error 0x80070003: Reading manifest from location: AppxManifest.xml failed with error: The system cannot find the path specified.

As you will see from the top of the last screenshot, there is a problem accessing a “.xml” file in the “C:\ProgramData\Microsoft\Windows\AppRepository” directory.
So off I go to said directory and lo and behold the error is quite right! The file it is looking for does not exist!

If you browse to the aforementioned directory you should find that it is full of “.xml” files for each of the Applications, likely many for different versions.
What I did next was to check for a similar named file albeit for a different version of the application and copy it. I then renamed it to that which the error was stating is missing.Voila! If I now attempt to install the specific App using:

Add-AppxPackage -Register “C:\Program Files\WindowsApps\<application folder>\AppxManifest.xml” -DisableDevelopmentMode

The install completes and I can then successfully launch the application again.

If you run the above cmdlet for each broken application and then use the suggested “Get-AppxLog” from the error output you can determine the file that is missing and needs creating.

In a couple of cases there wasn’t a similarly named file for me to take a copy from. In this case I copied one of the other Application “.xml” files, renamed it and edited the “.xml” contents to match the details of the App I was repairing.

Anyway, this successfully repaired ALL of my broken applications. I hadn’t seen this method posted elsewhere on the Web thus the reason for this post. Hopefully it helps someone else out there.

Good Luck!

 

Query Windows WMI Through NAT

I haven’t added any articles for ages, so here’s a fairly simple one…

One of the key things for SysAdmins is the ability to monitor the devices they’re responsible for. Pretty standard stuff and nothing new to anyone.

The most simplistic and universal method of doing so is to use the Simple Network Management Protocol (SNMP). It’ll give you all the standard things you usually want to know about your server(s), e.g. CPU, Memory and Disk usage.

Hello WMI
However it would probably useful and in some cases essential to also be able to monitor your standard Windows Applications or additional Windows Performance Counters otherwise unavailable through SNMP; e.g. IIS, SQL Server, Sharepoint to name just a couple.
For this you can utilise Windows Management Instrumentation (WMI). It’s worth noting that WMI can be used for more than simply querying/monitoring performance counters.
If you want to read more about the power of WMI, then read up on it here: About WMI

I won’t go into configuring WMI, there are plenty of articles on the Web that can help you with that, just use your usual Google foo.

The Problem
So if you’re only monitoring systems on your Internal LAN then you’re probably set to go. See ya later!

However in cases where you want to make use of WMI monitoring for remote devices over the public network, you’ll likely find your queries fail and time out.

The issue is WMI doesn’t work through Network Address Translation (NAT), or more accurately the Distributed Component Object Model (DCOM) doesn’t.

When you make your WMI query to your target, DCOM responds with a list of Hostnames and IP Addresses. Your client then pings these and uses the first one that responds.
For a device that is NAT’d the DCOM response knows nothing about the public IP Address, and thus none of the returned addresses will respond.

It is also worth noting that DCOM allocates ports dynamically, so you’ll need to keep an eye on your firewall rules, or look to restrict DCOM to a set of specific ports.

The Fix
The issue is actually fairly simple to resolve, the only reason I have written this article is I had to click around the web a few times before I discovered the reason behind the failure.

So to resolve the issue you just need to give your client a method to resolve the hostname that is returned by DCOM.
The simplest method of course is to use a hosts file entry on your client.
Assuming you configured WMI/DCOM correctly you should now find you can successfully query your remote NAT’d devices via WMI.

The drawback of course is, if you have a large number of remote NAT’d devices to monitor; you’re going to have a potentially large hosts file to maintain.

Another alternative of course would be using an Agent based monitoring method.
As an example Solarwinds Orion provides such a method which allows you to take advantage of WMI Monitoring without the NAT issue, other products may provide similar functionality.

Anyway, Happy Monitoring….

Failover Clustering: Correct Quorum but single node failure shuts down cluster

Another post on Windows Failover Clustering, but this one isn’t so pretty by comparison to my last post.

Recently on a 3 node Failover Cluster we were presented with a little warning that a node failure would cause the cluster service to stop and that the cluster configuration should be checked.
Well in a 3 node cluster the correct Quorum setting for an odd number of nodes is Node Majority and after double checking this was set correctly, that comms between all the nodes was in place and working and also running the Validation tool we were satisfied the configuration was indeed correct.
Obviously the last thing you want to risk is assuming the error is erroneous and then find that when a node fails the cluster also stops.

Satisfied the configuration was correct we presented the issue to Microsoft Support. The suggestion and indeed the resolution was as follows:

  1. Add a Witness disk to the cluster
  2. Change the Cluster Quorum setting to Node and Disk Majority
  3. Change the Cluster Quorum setting back to Node Majority

We didn’t get a reason for why this happens other than sometimes it does and switching to another Quorum setting and back again generally resolves the issue.

Hopefully this will save some people some head scratching and the need to contact MS support.

For full details on the correct Quorum configuration for Failover Clusters refer to the Technet Article: http://technet.microsoft.com/en-gb/library/cc770620%28v=ws.10%29.aspx

James

Windows Server 2012: Cluster Aware Updating

In my continued efforts over the past few weeks putting together a Windows Server 2012 Hyper-V Cluster, I recently discovered a nifty new feature to Windows Server 2012’s Failover Clustering – Cluster Aware Updating.

This feature is going to save a lot of SysAdmin time when it comes to patching your Failover Cluster nodes, the only real interaction required is simply to setup the schedule. Cluster Aware Updating will fully automate patching your cluster nodes one-by-one without impact to your cluster applications or roles.

Initial setup of CAU requires that you select a “Co-ordinator”, and this basically does what it says on the tin. The Co-ordinator manages and monitors the patching tasks across the nodes in the cluster. This role can be enabled within the cluster or outside.

The CAU Co-ordinator will perform the following steps -:

  • Download Updates to each node
  • Selects the node with the fewest applications/roles first (although you can specify a specific order during setup)
  • Initiates a Node Drain, i.e. moves the applications/roles off the node to other nodes in the cluster
  • Sets the node into Maintenance Mode
  • Installs the downloaded updates
  • Restarts the node if required
  • Verifies the installed updates
  • Brings the node out of Maintenance Mode
  • Moves the applications/roles that were previously moved off the node back again
  • Repeat the above steps for the next node in the cluster

As you can see performing those steps manually is a very time consuming task, especially for large clusters with many applications/roles. The most time consuming and tedious part being the application/role migrations and ensuring you move the same roles back again afterwards.

CAU can install updates from a number of sources including:

  • Windows/Microsoft Update
  • Windows Server Update Services (WSUS)
  • Hotfixes or Cumulative Updates not released via Windows/MS Update (setup a file share)
  • 3rd Party Driver and Firmware updates (setup file share)

So not only does CAU save you time but it ensures that your cluster nodes are all at the same update levels too which of course is desirable at all times.

One thing I did notice was the SCOM agent on the cluster nodes got stuck in Maintenance Mode. I had to fix this by putting the nodes into Maintenance Mode via the SCOM console for 10 minutes, after which the nodes were successfully monitored again.

This is certainly one of my favourite additions to the Server 2012 feature set so far. If you have a Server 2012 cluster then enable this feature!

 

James

SCOM 2012: Monitor Overrides for mixed Hyper-V 2008/2012 Environments

If you have an environment containing both Hyper-V 2008 and 2012 servers and thus have the Hyper-V 2008 Management Packs installed you’ll find you get some false alerts for your 2012 Hyper-V servers.

The 2008 Hyper-V Management pack looks for event logs that no longer exist in Hyper-V 2012 thus you’ll receive an alert stating an event log is inaccessible.

Example SCOM Alerts:

Alert description: The Windows Event Log Provider is still unable to open the Microsoft-Windows-Hyper-V-Network-Admin event log on computer ‘hostname’. The Provider has been unable to open the Microsoft-Windows-Hyper-V-Network-Admin event log for 720 seconds.

Alert description: The Windows Event Log Provider is still unable to open the Microsoft-Windows-Hyper-V-Image-Management-Service-Admin event log on computer ‘hostname’.
The Provider has been unable to open the Microsoft-Windows-Hyper-V-Image-Management-Service-Admin event log for 6480 seconds.

To resolve this you need to create an override that excludes your Hyper-V 2012 hosts from these monitors as follows:

  1. In the SCOM Management console navigate to Authoring > Management Pack Objects > Monitors
  2. Click Scope button at the top of the console, enter ‘Hyper-V’ > View All Targets > Select All > OK
  3. In the Look for field enter ‘Connectivity’ > Find
  4. For both ‘Port Connectivity’ and ‘Port Disconnectivity’ right click the Monitor > Overrides > Disable the monitor > For a specific object of class
  5. You should see your Agent managed Hyper-V hosts, tick the 2012 Hyper-V Hosts > OK
  6. Back to the Look for field enter ‘mounted drive’ > Find
  7. Find the ‘Mounted Drive Read-Only’ monitor > Right click > Overrides > Disable the monitor > For a specific object of class
  8. Select your 2012 Hyper-V hosts > OK

I found the alerts didn’t recover automatically after adding the overrides and had to manually mark them as resolved/closed.

 

James

 

SCOM 2012 SP1: Broken Alert Link URL

I’ve been working on a System Center Operations Manager (SCOM) 2012 deployment recently. Now that Microsoft have made Service Pack 1 fully available it appears the normal Alert URL is somewhat broken.

The original Alert URL looks something like this: http://scomwebserver/OperationsManager/default.aspx?DisplayMode=Pivot&ViewType=AlertView&AlertID=$UrlEncodeData/Context/DataItem/AlertId$
However since the installation of Service Pack 1 the Alert View never actually completes loading.

The workaround for the time being is to update the Alert URL in your Channel Notification to: http://scomwebserver/MonitoringView/default.aspx?DisplayMode=Pivot&ViewType=AlertView&AlertID=$UrlEncodeData/Context/DataItem/AlertId$
This works, but you must first authenticate at the /OperationsManager URL first as it appears that authentication fails if you browse to the MonitoringView without having visited the OperationsManager URL first!

A pretty irritating problem, hopefully it won’t take long for MS to release a fix. Cumulative Update 1 for SP1 was released pretty quickly after the release of SP1.
I’ll post an update once a fix has been released.

James