Showing posts with label Troubleshooting. Show all posts
Showing posts with label Troubleshooting. Show all posts

Thursday, October 06, 2016

SQL Server Configuration Manager - Invalid class [0x80041010]

This is the second blog post that I wrote about troubleshooting of SQL Server Configuration Manager. This time, or a forgotten number of times, I start Configuration Manager but it returns an error like below:

Cannot connect to WMI provider. You do not have permission or the server is unreachable. Note that you can only manage SQL Server 2005 and later servers with SQL Server Configuration Manager. Invalid class [0x80041010]

Sounds like the code [0x80041010] is a good starting point. Did a bit of research, and found Michael Aspengren's blog post about it (see reference below).

So first, open the command prompt with Run as administrator and navigate to the C:\Program Files(x86)\Microsoft SQL Server\100\Shared\

then run the following command: mofcomp sqlmgmproviderxpsp2up.mof

The output should look like these:

Microsoft (R) MOF Compiler Version 6.1.7600.16385
Copyright (c) Microsoft Corp. 1997-2006. All rights reserved.
Parsing MOF file: sqlmgmproviderxpsp2up.mof
MOF file has been successfully parsed
Storing data in the repository…
Done!

And Wola!! SQL Server Configuration Manager should starts without a problem!! Thanks again, Mike!! :)

Reference
"SQL Server Configuration Manager" gives "Invalid class [0x80041010]” when starting.

Wednesday, February 11, 2015

Troubleshooting - Failed to write file data on cluster disk 1 partition 1, failure reason: The disk structure is corrupted and unreadable

One of the initial task in setting up a windows cluster for SQL failover cluster, is to validate if the servers fulfill all the network, storage, hardware and software requirements. It helps you to work through the setting up and straights things up before the really deal.

Sometimes, it is a step with full of surprises, especially when you don't have the control over how the server was set up. To be fair, it is quite a list of items and it is fair to say my network/system team missed on one or two things, which is still acceptable. Validation is like a QC check against the built servers to match the standard. On the other hands, some issue would just a pure kind of jerk that shows up to make your hard day harder.

I have the following issue returned, on the storage section, which make me and my network/SAN dude scratch our head a bit. The "Validate a configuration" check shows:

Interestingly, new shared drive created at the SAN shows up as corrupted. I tested the drive and I can read and write to it. It just not pass the validation. First come to my mind, is to reformat the drive 1 from the disk management msc. And that doesn't help. Indeed, I realise that the approach was wrong.

I researched on a few forums to look for the solution. First everyone suggested that (potential) Cluster Disk 1 doesn't corresponding to the physical disks which listed in the disk management msc. To determine what disk is the troublemaker, we need to check the List Potential Cluster Disks at the storage section in the validation report, then take a note of the disk ID. For example, I have an issue with Cluster Disk 1, and look up the list of potential cluster disks give me the ID c188f5ac:

Then, from the List All Disks, which lists any disk attached to the servers, we can then identify the disk in trouble with the disk ID mentioned above.

Now that we know which disk requires our attention, so let's get the solution out. There is a few potential reason that may contribute to the symptom that "The disk structure is corrupted and unreadable". I have a disk drive issue, what should I do? It sounds like one of my old days job interview question.

It would be the old school "chkdsk /f". The truth is, if you found 1 drive shows up disk drive issue, I would run chkdsk against all the drives, just in case. In my case, there are 3 drives out of 8 reported with drive issue, and "chkdsk /f" just fixed that.

Friday, July 11, 2014

To find out which domain controller you are authenticated to on ther server ?

I was helping my friend in finance to check out some issue in test environment, and of course, which starts as "hey, we got some database issue since we can't connect to to backend...". Great pick up line as usual.

So my friend shows me his database issue, and I can point it out straightaway that it is an authentication plus DNS issue rather than database. It rings the bell that my OP team friend told me about a project that they are looking at upgrading the domain controllers and it is reasonable that they are doing a rehearsal for the big date.

There is 2 active directory servers online and I am not sure which one the application server is authenticated from. Well, I found the following handy environment variable for just the job: