I needed to remove an MSDE instance from the SQL Server Service Manager because it no longer existed and I was annoyed by the error message I was receiving each time I logged onto the server. After to many unsuccessful Google searches, I just decided to open the registry and fire up the good old "F3" ("Find Next" function -- also found via the Edit menu) to look for the name of the instance I was trying to get rid of to see if I could edit it manually.
THANK GOD! It was actually extremely simple and successful.
If ever you run into the same situation as me, here is the registry key and the value you are looking for:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\InstalledInstances
It is a Multi-String Value (REG_MULTI_SZ) and it's as easy as removing the instance in question from the list.
Wish I would have felt like spending a few minutes doing this months ago.
Tuesday, October 21, 2008
Monday, July 21, 2008
The API Remoting Web Service is not working
So, ever since I upgraded from WSUS 2.x to 3.x, I have been seeing this error in my Application log. I couldn't find anything broken, I just kept seeing this error. After countless searches on Google and many hours wasted--I gave up. This morning I decided I really didn't like this error, so I decided to giver 'er another go.
As I'm staring at the values in this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup
I notice that the String "HostHeader" contained the external DNS FQDN instead of the Internal. I figure "that's odd", so I change it to the local DNS FQDN, host.domain.local. after all, I'm only running WSUS internally. Sure, I host our .com zone internally so things like OWA can be accessed from inside without having to give users yet another URL, but I figured that in this case, WSUS should be using the local FQDN no matter what.
SUCCESS!!
I went from basically seeing the Event ID 12012 about 4 or 5 times a day to not seeing it at all. Whowuddathunkit?
"The simplest things are ALWAYS DNS!"
- I checked all the File Permissions as directed by TechNet
- I checked all the Registry permissions as directed by TechNet
- I checked all the ISS permissions as directed by TechNet
- I restarted IIS, Reset IIS, & restarted the WSUS Service
- I ran wsusutil.exe checkhealth
As I'm staring at the values in this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup
I notice that the String "HostHeader" contained the external DNS FQDN instead of the Internal. I figure "that's odd", so I change it to the local DNS FQDN, host.domain.local. after all, I'm only running WSUS internally. Sure, I host our .com zone internally so things like OWA can be accessed from inside without having to give users yet another URL, but I figured that in this case, WSUS should be using the local FQDN no matter what.
SUCCESS!!
I went from basically seeing the Event ID 12012 about 4 or 5 times a day to not seeing it at all. Whowuddathunkit?
"The simplest things are ALWAYS DNS!"
Thursday, January 3, 2008
"It's Always DNS"
This is a phrase that I say quite often. Why? Because it often holds true. When things aren't acting as they should, and you've checked the physical layer (remember kids, "physical layer first!") DNS is the next place to look.
So why do I say "it's always DNS"? It is the most common answer to the most confusing scenarios. For example, why can't Susan use app x when Bill is having no issue with it? Or how come Susan's Outlook is working just fine, but Bill can't seem to open his passed the splash screen? In these cases--check DNS.
First step is to check things at the client-side. Do this by flushing the DNS cache via the command line:
c:>ipconfig /flushdns
Next, try to ping the hosting machine:
c:>ping AppServerInQuestion
If the pings reply, great! Try the app or service again. If the pings do not reply, flush the client again and move on over to the DNS server to have a look at what's going on. This is where knowing your environment will be key.
Take a look at the Forward Lookup table and make sure that there is only one entry for the machine in question. For an easy way to do this, sort by hostname to easily find the host in question. Also, sort by IP address and verify it is only listed once for this host.
Some common signs that a problem may be related to DNS:
Error messages in the Event Logs are a big help in troubleshooting issues.... and when troubleshooting anything, remember to ask yourself "What changed?" as that can always clue you in to what's going on.
Other useful resources are places like EventID.net and just a plain Google search. Sometimes I've found that a Google search is more useful or more helpful than any other resource on my list.
So why do I say "it's always DNS"? It is the most common answer to the most confusing scenarios. For example, why can't Susan use app x when Bill is having no issue with it? Or how come Susan's Outlook is working just fine, but Bill can't seem to open his passed the splash screen? In these cases--check DNS.
First step is to check things at the client-side. Do this by flushing the DNS cache via the command line:
c:>ipconfig /flushdns
Next, try to ping the hosting machine:
c:>ping AppServerInQuestion
If the pings reply, great! Try the app or service again. If the pings do not reply, flush the client again and move on over to the DNS server to have a look at what's going on. This is where knowing your environment will be key.
Take a look at the Forward Lookup table and make sure that there is only one entry for the machine in question. For an easy way to do this, sort by hostname to easily find the host in question. Also, sort by IP address and verify it is only listed once for this host.
Some common signs that a problem may be related to DNS:
- Mapped drives are not there, or not connected
- Remote administration tools are hanging or just not working
- Outlook mysteriously isn't working
- A ping to a host hangs, even though you can see that it is on and connected
- A ping to IP is successful, but a ping to a hostname is not
Error messages in the Event Logs are a big help in troubleshooting issues.... and when troubleshooting anything, remember to ask yourself "What changed?" as that can always clue you in to what's going on.
Other useful resources are places like EventID.net and just a plain Google search. Sometimes I've found that a Google search is more useful or more helpful than any other resource on my list.
Subscribe to:
Posts (Atom)