One DBA's Ongoing Search for Clarity in the Middle of Nowhere


*or*

Yet Another Andy Writing About SQL Server

Showing posts with label Windows 2008. Show all posts
Showing posts with label Windows 2008. Show all posts

Monday, May 23, 2016

How Do I Change My Domain Password on Windows Server 2012?

As a DBA I spend a lot of time in RDP sessions, both to SQL Servers and to "jump"/pass-through servers on client domains.  Most clients (unfortunately not all of them - security is important, people!) have some variant of password expiration in their domains requiring regular password changes every 30/90/180 days.

Prior to Windows Server 2012, this was relatively straightforward - in the Start Menu select "Windows Security" (sometime hidden under Administrative Tools>>Windows Security):


...which then gives you a friendly menu where you can choose to "Change A Password":



Easy right?

** Often unknown tip - from the Change Password Prompt:



You can edit the top line to any account to which you have access - your accounts in other domains (assuming there is access to domain controllers in the other domain) or even other accounts altogether!  Even though I am logged into the above server as DOMAIN\agalbraith, I could modify the line to change the password for SOMEOTHERDOMAIN\agalbraith or DOMAIN\SQLServiceAccount,

--

The catch to all of this is that in Windows Server 2012, the easy method...went away.  How could they do that???

https://themuseletter.files.wordpress.com/2014/11/61225_bill-gates-shrug.jpg

The Windows Security box is Dead....Long Live the Windows Security box!

--

Here are three different ways to get to the same screen in Windows Server 2012.  These three methods work in Windows Server 2008 and 2008 R2 as well, so once you get used to one of them you can use it on your old servers as well.

http://cache.gawker.com/assets/images/gizmodo/2009/08/old_pc.jpg
Maybe not *that* old....

--

The first method is the one I have known for a long time, and is very simple.  Instead of CTRL-ALT-DEL, use CTRL-ALT-END.  Most of the time, this takes you to the same prompt screen as we saw above:


--

The second method is a little more involved, but useful - and I have been in at least three situations where I *had* to use it - once when there was a keyboard mapping error in the RDP session (something I have only ever experienced once) and twice where I was several layers deep in RDP (RDP to RDP to RDP).  I found this method at http://www.tomshardware.com/answers/id-1629393/change-password-ctrl-alt-del-rdp-rdp.html.

From a command prompt, type osk to bring up the On-Screen Keyboard (something I didn't know even existed at the time):


With the OSK up, press CTRL and ALT on your actual physical keyboard, and then click DEL on the OSK (CTRL-ALT-DEL all on the OSK just functions like a regular CTRL-ALT-DEL):



BOOYAH!

--

The third method was recently offered up by a member of the team here at Ntirety, Mike Skaff.  It is one more example of #YouCanDoAnythingWithPowerShell.

I don't know where Mike found it, but I was able to find references in a couple of places, including http://wiki.mundy.co/Change_password_on_Remote_Desktop_Server_2012

From a PowerShell prompt, enter the following:
(New-Object -COM Shell.Application).WindowsSecurity()

Sure enough:


Like the OSK method above, this PowerShell method works from RDP in RDP in RDP as well - and it's PowerShell!

--

Hope this helps!


Wednesday, April 23, 2014

Where are my 32-bit Perfmon Counters?

I have run into this before, but not in this same way, so I decided it would be worth writing about.

On a client server they are running 32-bit SQL Server 2005 (I know, not supported - that's a different rant/post) on a 64-bit Windows 2008 installation.  When I logged onto the server for the first time to try to pull some basic data, I was greeted with one of the most-hated items of dealing with 32-bit SQL Server on a 64-bit operating system:

NO PERFMON COUNTERS!!!!!!

Public Service Announcement - Always *always* install your applications with the same architecture as your O/S - meaning always install only 64-bit applications on your 64-bit Windows Server!

Having seen this before, I went to the first item in my 32-bit toolbox - the WOW64 version of Perfmon located at C:\Windows\WOW64\perfmon.msc.  Many people don't seem to know this exists, but it allows you to access the 32-bit version of Perfmon required to access the counters for 32-bit SQL Server (or any other 32-bit application with performance counters) on a 64-bit Windows machine.

No Good.

I placed a shortcut for the 32-bit Perfmon on the desktop for future use (regardless of how I eventually resolved the issue, I knew I would definitely need to use the 32-bit Perfmon) and went to Management Studio to see if the counters were in sys.dm_os_performance_counters, which they were.  This showed my that the counters did exist - if they were completely missing or broken, they wouldn't be visible in the DMV either.

In the past when I had run into this issue, it had been on SQL Express and the counters didn't exist at all - not even in the DMV.  In those situations the answer was to load the counters via lodctr after copying them from another machine of the same version.  Since the counters existed I didn't believe that would be the answer (although eventually it was close - keep reading) so I turned to my Google-Fu to see where I should go next...

...and didn't find much.  A few forum postings and blog articles with different symptoms and different resolutions, but nothing AHA.  In my frustration I went through the steps to repair or reload the existing counters in case some of them were corrupted somehow.

First, I tried to just rebuild the existing counters via lodctr /R but that did not resolve the issue.

Next I went through the full steps to unload and reload the counters as described here by Alex Pinsker (blog/@alex_pinsker).  The catch is that near the end of the process Alex calls for a server reboot, and this was a production server.  I tried several things that I could do without impacting production, including:
  • Re-syncing the counters with WMI (WINMGMT.EXE /RESYNCPERF
  • Restarting the "Performance Logs and Alerts" service
  • Restarting "Windows Management Instrumentation" (WMI) service
  • Restarting the "Remote Registry" service (which shouldn't have mattered since I was trying to access the counters locally, but it isn't impactful to try)
...but it didn't work.  I gave up for the afternoon after coordinating a reboot for overnight with the client's server team.

A new day, and BINGO - I could see the SQL Server counters in the 32-bit Perfmon via the interactive ("real-time") Performance Monitor after the reboot. 

With counters firmly in hand, I went to the next step - trying to set up a data collector.  I went through the basic steps to set up the collector and started it, and then a short time later I stopped and re-started the collector to view the contents of the perf file.

ARGH- no SQL Server counters.  The Windows hives of counters (Processor, Logical Disk, etc.) were there, but no SQL Server counters.

I had initially opened the perf file by double-clicking it, so, just to make sure, I opened 32-bit Perfmon manually via my shortcut and changed its data source to my perf file just in case that was the issue, but no good.

More than a little Google-Fu later and I finally found something that described my situation pretty well, from a Microsoft CSS Engineer in Romania: http://blogs.technet.com/b/roplatforms/archive/2010/05/03/creating-a-custom-data-collector-set-with-sql-x86-counters-on-an-x64-os.aspx

The engineer, Bogdan Palos, was writing about a situation on Small Business Server (SBS) compared to Windows 2008 X64, but the basic scenario was similar - trying to create a data collector of 32-bit counters on a Windows 2008 X64 installation.

The suggested fix seemed more than a little bizarre:
...copy the 64bit version of “sqlctr90.dll” from another machine running a x64 SQL instance, to the “c:\windows\system32” directory of the Server 2008 x64 OS machine running SQL Server 2005 x86. We recommend using the DLL from similar SP levels of SQL Server
Apparently the files from the x86 SQL Server installation are not enough - you actually need a file from an X64 install?

But guess what - it worked!  After simply copying the sqlctr90.dll file from another SQL Server 2005 X64 of the same version number into the c:\Windows\system32 directory on this server and re-starting my Perfmon collector, it began collecting the SQL Server hives of counters.

Just one more little thing to file under "Seriously, Microsoft?"

What did I learn?
  • 32-bit is evil (already knew this, but it was definitely reinforced).
  • Microsoft will never cease to amaze me in how some things need to be hacked to work.
  • There is always something else to learn!

Hope this helps!

Friday, October 8, 2010

How *Not* To Install SQL 2008 R2 - A Cautionary Tale

I was recently tasked with adding a SQL Server 2008 R2 instance to an existing three-node Windows 2008 cluster that was already hosting two SQL 2008 (not R2) instances.  I fired up R2 setup on the first node and received the following error (retrieved from C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\20101005_104106\Summary_<server>_20101005_104106_ComponentUpdate.txt):

Overall summary:
  Final result:                  Failed: see details below
  Exit code (Decimal):           2064843076
  Exit facility code:            787
  Exit error code:               324
  Exit message:                  MsiGetProductInfo failed to retrieve ProductVersion for package with Product Code = '{FBD367D1-642F-47CF-B79B-9BE48FB34007}'. Error code: 1608.
  Start time:                    2010-10-05 10:46:00
  End time:                      2010-10-05 10:53:03
  Requested action:              ComponentUpdate

Like pretty much every DBA I know, I went to my primary troubleshooting tool, Google (sorry Bing) and looked for “MsiGetProductInfo failed to retrieve ProductVersion for package” – this led me to this blog by Dibakar Dharchoudhury  (Sanjayap on MSDN) about a similar but related problem he encountered when upgrading SQL 2005 to 2008.

The amazing part of this to me (I would love to read something by an MVP or MCM explaining why this is this way) is the following bit describing how to find the offending registry entries:

Get the Product Code = '{0826F9E4-787E-481D-83E0-BC6A57B056D5}' from the error message that you are getting.

Byte reverse the first part from 0826F9E4 to 4E9F6280.

Search in the registry under HKEY_CLASSES_ROOT\Installer\UpgradeCodes and try to find a match.

Take a backup of the registry and delete the parent key.

You have to byte-reverse the first “octet” to find it in the registry?  Seriously?

So I attempted this, changing FBD367D1 to 1D763DBF, and was able to find two offending entries, which I deleted and then continued on past that stage of Setup.

…and then found I had made a more crucial error:

I didn’t have enough free space on my C: drive – a horrible rookie-type mistake that unfortunately was staring me in the face.  I needed at least 4.9 GB free and I only had 3.5 GB – with insufficient temp or user data I could clean – ouch!

I made the mistake of assuming “this is a relatively new server cluster – the C: drive will be OK” – WRONG! – ALWAYS CHECK!

At least we learned something else – we are fairly new at rolling out Windows 2008 in our environment and didn’t realize that the 32 GB C: drives we have been using standard for Windows 2003 won’t quite work with Windows 2008, where C:\Windows is now ~10 GB larger at install (and will get even larger over time) due to an architecture change related to the C:\Windows\WinSXS folder (as described here by Joseph Conway, an escalation engineer at Microsoft: )

So, I worked with our Storage person and Server staff and we got the C: drive expanded to 50 GB overnight – the next morning I tried the install again and received this error:

MSI (s) (1C:BC) [12:32:13:163]: Specified instance {FBD367D1-642F-47CF-B79B-9BE48FB34007} via transform :InstID01.mst;:InstName01.mst is already installed. MSINEWINSTANCE requires a new instance that is not installed.

That was a new one to me, so I Google’d “MSINEWINSTANCE requires a new instance that is not installed” and “SQL 2008” to see what I could find…not much – various errors related to a given instance name already existing, or various Reporting Services install-related errors that talk about finding the offending GUID in the registry and deleting it (sound familiar?) So I fired up regedit, and searched for the instance ID in the error message – nothing.

After reading some more and spinning my wheels for a half hour or so I remembered my issue from the previous day, and sure enough, the instance code matched the offending product code from that attempt, and byte-reversing the first “octet” of the instance code from FBD367D1 to 1D763DBF allowed me to find it in the registry.

46 times.

Apparently the failed attempt (with insufficient C Drive space) had left 46 hooks in the registry referring to that code – all of them in the

HKLM>SOFTWARE>Microsoft>Windows>Installer>UpgradeCodes

and

HKLM>SOFTWARE>Microsoft>Windows>Uninstall

registry hives.

So I went through and cleaned them out, and whadyaknow -  my install went through successfully – workstation tools, etc. upgraded from 2008>>>R2 and new R2 instance ready to go.

So - lessons of the day:

(1) Windows 2008 takes up more room on the system drive than you may be used to - thanks Joseph Conway @ Microsoft!

(2) Always check for byte reversed product codes if you can't find the straight product code in your registry (checking context once you do to make sure you aren’t about to delete the registry keys for your virus software or some other non-related software!) – thanks Dibakar Dharchoudhury!

(3) ALWAYS CHECK YOUR C: DRIVE TO MAKE SURE THERE IS ENOUGH FREE SPACE *BEFORE* YOU INSTALL SOFTWARE!

Learn from my mistakes and have a great day!  {-: