Latest notes

Change port used by Exchange 2007 or 2010 send connector when using smarthost

http://exchangeshell.wordpress.com/2010/02/16/change-port-used-by-exchange-2007-or-2010-send-connector-when-using-smarthost/

To find the ports used by all your send connectors along with the smarthost used just open the shell and type:

Get-SendConnector | ft Id*,Sm*s,po*

Now, to send the port to something different just run Set-Sendconnector. So if the connector is called “OutboundMail” and you want it to use port 3535 it would be:

Set-SendConnector “OutboundMail” -port 3535

Modifying SBS 2003 SP1’s bkprunner.exe for Improved Backup Performance

http://blog.chrisara.com.au/2007/09/modifying-sbs-2003-sp1s-bkprunnerexe.html

 

I’ll quickly jot this down before I forget.
I’ve recently been having a shrinking backup window on one of my client’s SBS 2003 boxes. It backs up to tape and I didn’t want to create a backup script and lose the nice reporting features that SBS provides. So I hacked the bkprunner.exe process instead 🙂
On my own SBS 2003 box I was getting terrible server performance during my daily backup to USB drives. I found the undocumented /FU switch that was included with the SP1 version of ntbackup and some registry modifications that the Exchange team of Microsoft IT performed to improve their backup performance.
Open Explorer and go to "C:\Program Files\Microsoft Windows Small Business Server\Backup"
Make a copy of bkprunner.exe

Download and extract XVI32.
Run XVI32.exe
Open bkprunner.exe in XVI32
The address range $10F0-$11B7 is used for backups to .bkf files
The address range $11B8-$1277 is used for backups to tape
To turn off verify when backing up to a .bkf
Go to address $113A
In the hex pane (the middle one), type in the following hex values:
6E 00 6F 00 20
This enters in the text "no " in Unicode format.

To turn off buffered writes (as explained in MSKB 839272 and also here) when backing up to a .bkf – recommended
Go to address $115E
In the hex pane (the middle one), type in the following hex values:
46 00 55 00 20 00 20 00 20 00 20
This enters in the text "FU " in Unicode format.

To turn off verify when backing up to tape
Go to address $1202
In the hex pane (the middle one), type in the following hex values:
6E 00 6F 00 20
This enters in the text "no " in Unicode format.

Registry modifications for performance
Run regedit
Open HKEY_USERS
Load Hive
Open SBS Backup User’s NTUSER.DAT registry hive; call the key name BACKUP
Browse to HKEY_USERS\BACKUP\Software\Microsoft\Ntbackup\Backup Engine.
Edit the value of the entry Logical Disk Buffer Size from 32 to 64.
Edit the value of the entry Max Buffer Size from 512 to 1024.
Edit the value of the entry Max Num Tape Buffers from 9 to 16.
If the above keys don’t exist, create them as String values.
Click on HKEY_USERS\BACKUP
Unload hive

VBA tip: Limit the number of times a file can be opened

http://blogs.office.com/b/microsoft-excel/archive/2012/01/04/vba-tip-limit-the-number-of-times-a-file-can-be-used.aspx

Using a demo of a file—not allowing it to be used more than x times

Suppose you want to send out a demo version of a file for a user to examine, but you don’t want it used more than a certain number of times, perhaps without your being paid for it. There are a lot of possible approaches for this situation, but here I’m going to show the use of some simple VBA statements called SaveSetting and GetSetting.

Here’s a screenshot of the whole procedure. It’s run each time the workbook is opened. If the VBA code is password protected, the user will not be able to easily prevent the demo program from ending.

VBA code that runs when the workbook is opened
The syntax for GetSetting is:

Syntax for GetSetting
…and for SaveSetting is:

Syntax for SaveSetting
Each of the parameters is an arbitrary name you supply to access information stored in or read from the registry.

The AppName is more like a major category, the Section is a subcategory and the Key is yet another category. It gets clearer with the example. The first time this workbook is opened, the statement
N=GetSetting(“Demo”,”Demo”,”Demo”,0)+1 is executed. The 4th parameter is the default value given if no setting is actually already stored. So the first time, the GetSetting returns 0. Adding 1 to this stores a 1 into variable n.

So n is not 5 (yet), and it runs into the SaveSetting. The statement SaveSetting “Demo”, “Demo”, “Demo”,n now stores the value 5 in the registry. The next time the workbook is opened, the Getsetting returns that 1, and 1 is added to it and stored in n. Still not 5, and now a 2 is stored in the registry, etc. Eventually, the GetSetting returns 5, n is 6, and the program quits after giving a message to the user.

To reset this to zero on your own machine, you can either run SaveSetting “Demo”, “Demo”, “Demo”, 0, or you can run another variation of the VBA, called DeleteSetting. This syntax is:

Syntax for DeleteSetting

As you can see, the Section and Key are optional. So executing DeleteSetting “Demo” clears the registry of the AppName as well as Section and Key.

Using GetSetting, SaveSetting, DeleteSetting can enable you to also communicate between sessions of Excel, or one of my favorite ways to use it is in debugging. I have frequently come across some stumpers where the VBA code crashes and I’m unable to pinpoint where that happens. This is with over 40,000 lines of VBA code (yes, a very large and intricate set of macros!). The idea of single stepping through the code is good, but there are times when I do that, then the error doesn’t occur! So I intersperse my code with random lines of something like SaveSetting “X”, “X”, “X”, 1 and SaveSetting “X”, “X”, “X”, 2 and SaveSetting “X”, “X”, “X”, 3, etc. Once the program crashes, I start up Excel and run this line in the immediate window: ?GetSetting (“X”, “X”, “X”) and if it returns 2, for example, then I know the program crashed between the SaveSetting that produced a 2 and the one that produced a 3. It has helped.

Lastly, the value stored is not limited to numbers as I’ve shown in this example—it can be any string you want, using it like a storage area for any purpose.

— Bob Umlas, Excel MVP

Link to more information about the Program Install and Uninstall Troubleshooting Tool

http://blogs.msdn.com/b/astebner/archive/2011/11/23/10241056.aspx

There is a new general-purpose installation troubleshooting tool called the Program Install and Uninstall Troubleshooting Tool that has been available on the Microsoft support site for a little while, and I want to post some information about this tool to help make it easier for people to find it.

This tool is conceptually similar to the .NET Framework cleanup tool, but it is more generic and can be used to clean up any MSI-based installation on a computer. It also performs more robust back-up steps prior to cleaning up in case you need to roll back to a previous state.

Where to download the Program Install and Uninstall Troubleshooting Tool

You can find more information about the Program Install and Uninstall Troubleshooting Tool and download it from the following locations:

Summary information about the tool

The Program Install and Uninstall Troubleshooting Tool can be used to automatically diagnose problems that can prevent installing and uninstalling programs on your computer. It can help resolve some errors that prevent programs from uninstalling, installing or updating correctly. Here is a list of issues that this tool is currently able to fix:

  • Resolves some problems that can prevent programs from being successfully uninstalled (which can block re-installations and update installation).
  • Removes an incorrect registry key that can cause some installers to fail on 64-bit operating systems.
  • Fixes corrupted patch data in Windows Installer registry keys.

This tool is designed as a last resort for cases where install, uninstall, repair or patch installation did not succeed for unusual reasons. It is not a substitute for the standard uninstall procedure. You should use only use this tool to uninstall a program if the program fails to uninstall using the entry in the Programs and Features control panel.

More details about how the tool works

The Program Install and Uninstall Troubleshooting Tool does the following behind the scenes when you use it to uninstall a program:

  • Creates a system restore point prior to removing program files and registry entries. This restore point can be used to return the computer to the state prior to any action taken by the tool.
  • Makes back-up copies of all files and registry entries that it will remove to a folder under c:\MATS\<ProductCode>.
  • Backs up files in sub-folders that correspond to the system drive letters. For example: c:\MATS\<ProductCode>\FileBackup\c\…
  • Backs up registry information in an XML file.
  • Creates a PowerShell script that can be used to automatically restore file and registry information deleted by the tool. The PowerShell script will be located at C:\MATS\<ProductCode>\RestoreYourFilesAndRegistry.ps1, and you can double-click on it to run it if you have PowerShell installed.
  • Stores additional information in the registry about actions that it has taken. This information can be found at the following location:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MATS\WindowsInstaller\<ProductCode>\<DateTime>
    The most useful piece of information stored at this location in the registry is the return value received when MATS attempted to run msiexec /x to uninstall the product.

The Program Install and Uninstall Troubleshooting Tool requires Windows Installer product codes in order to know what file and registry information to remove from the computer. For programs that are listed in the tool UI, the product code will appear as a tool tip when you mouse over the product name. If you choose the Not Listed option in the tool UI, you can use a tool like MsiInv to determine the product code.