Parameter Hunting: Part II

In my last post on the subject, I discussed the concept of using Process Explorer to discover switches you can use for unattended installs/uninstalls used in enterprise software deployment.

Like before, I have a pesky setup.exe package that wants to guide me through an installation GUI, and would not respond to the usual setup.exe /s /q etc. and so forth…

This particular installer was for a very obscure serial hub manufacturer so there was Googling my way out of this; instead I needed to figure out what was used to build the installer, then work backward from there.

Once against, I launched my trusty Process Explorer (as Administrator) and inspected the setup.exe’s process…to my delight, scrolling down the “Strings” tab I came across this:

Note the string, “This installation was built with Inno Setup.” With that in mind, I was able to look up the documentation associated with the package builder to discover the built-in parameters I needed for silent installation.

While this specific technique might not work for every situation, it never hurts to have another tool in your toolbox!

Reestablishing Trust Between a Workstation and Domain When the Local Administrator account is Disabled

Disclaimer: Circumventing windows security should NOT be taken lightly, and should only be used by an authorized person as a last resort in the course of recovery or repair. Mumbo Jumbo aside, remember that YOU ALONE are responsible for your own actions, so be sure that you know what you’re doing before making any changes!

From time to time, a workstation (usually a laptop) becomes disjoined from your domain, and starts throwing the following error:

"The trust relationship between this workstation and the primary domain failed."

When this happens, any attempt to login using a domain user account will fail. The traditional fix goes something like this:

  1. Log in using a Local Administrator Account
  2. Swap the domain membership to a workgroup (e.g. TEMP)
  3. Reboot and log back in (Local Administrator Account)
  4. Change the workgroup back to the domain

But what if the local user account is disabled, you’ve forgotten the password or someone changed it? That’s where Hiren’s Boot CD comes in!

If you’re not familiar with Hiren’s Boot CD, you’re missing out on a wealth of tools that can you help you recover data, clear viruses, and even reset passwords! In this scenario, we’re going to use the Offline NT Password Changer.

  1. Insert Hiren’s Boot CD and boot from your optical drive
  2. Navigate to the Offline NT/2000/XP/Vista/7 Password Changer
  3. Next, select the partition where Windows is installed (usually C:\)
  4. Verify that you’re using the correct Registry Path (usually Windows/system32/config)
  5. At this point, you can elect to enable disabled accounts (if the local Administrator account is diabled) and/or change the password. In either case, you’ll need to enter the username you’d like to edit – I would recommend a default user account (e.g. Administrator)
  6. When done, press ! to quit the editor, followed by Y to confirm your changes
  7. Remove Hiren’s Boot CD and reboot

I hope this helps someone! Feel free to post your comments or questions.

Further reading:

Disabling SSL v2 in Server 2008 x64 and Server 2008 R2

Disclaimer: Always back up your registry prior to making changes!

Incorrect entries can cause unexpected behavior, and may even render your operating system unusable! I disclaim any responsibility for damages, loss of data or any other issues resulting from registry changes.

While this worked for me, every environment is different, so use this at your own risk!

I recently assisted a client with getting a Windows Server 2008 R2 machine in compliance with Payment Card Industry (PCI) standards.

PCI compliance is very important for eCommerce sites and anyone handling credit card information.

We used a 3rd party testing tool that scanned for open ports, SSL version support, as well as allowed encryption/cipher combinations. The first few tests failed due to SSL 2.0 support in Server 2008 R2/IIS7.5.

I found an article on Microsoft’s support site which described how to disable IIS protocols by modifying the registry (this can’t be done through IIS Manager):

Here’s where it gets confusing. I followed the instructions and browsed to:


As the article points out, the “SSL 1.0,” “SSL 2.0,” “SSL 3.0” subkeys are typically there. Note the use of the word Typically rather than Always, meaning that sometimes they’re bloody well NOT there, as was the case with my server!

The article goes on to say, “create a new DWORD value in the server subkey of the protocol.” I have big problem with this phrasing given the ubiquity of the word, “Server.” The instructions do not explicitly tell you to create a new subkey under “SSL 2.0” called “Server” and to place the DWORD in there, so naturally, I wrongly assumed that the DWORD went in “SSL 2.0” instead, which didn’t work.

After a little digging, I came across another a post on the forums by a user named Pawel Dolny who did a much better job of explaining things:

When you follow his article, be sure to create subkeys called “Server” and “Client” in each of the SSL protocol keys, then add a DWORD in each called “Enabled” with a value of “0” to disable it (or 1 to enable it, as would be the case for SSL 3.0).

He also covers enabling/disabling ciphers. Once you’ve rebooted, you can test your site to verify the changes:

I hope this helps someone!

Retrieving a copy of all Emails Sent To or Received From a Specific Domain in Exchange 2007

I recently received a request to locate and create a copy of every email sent to or received from a specific domain. Exchange 2010 possesses some inherent litigation hold and compliance management tools that could do this for you, and I even found a VB script for Exchange 2003, there was not much information out there for Exchange 2007.

Here’s what I did…

Step 1: Ensure that your account has “FullAccess” permissions to all mailboxes in your Exchange Database by running this command in Exchange Management Shell:

get-Mailbox -Database "[Database Name]" | Add-MailboxPermission -User [Your Admin Acocunt] -AccessRights FullAccess -InheritanceType All

Step 2: This hefty commandlet tells Exchange to search every mailbox in the database for a messages received from a specific domain, excluding the target mailbox as you can’t export a mailbox to itself:

Get-Mailbox -Database "[Database Name]" |?{$_.Name -ne '[Username of the Target Mailbox]'} | Export-Mailbox -TargetMailbox [Username of the Target Mailbox] -TargetFolder [Name of Folder] -senderKeywords:'*[domain name]'

Step 3: The last command does the same as the above, but looks for any emails sent to a specific domain:

Get-Mailbox -Database "[Database Name]" |?{$_.Name -ne '[Username of the Target Mailbox]'} | Export-Mailbox -TargetMailbox [Username of the Target Mailbox] -TargetFolder [Name of Folder] -recipientKeywords:'*[domain name]'

Once done, you can open the target mailbox in Outlook and save it to a PST. So there you have it!