Exchange intelligent message filter update fails, Exchange then not running

So I try and dutifully run Windows Update on my SBS2003 box.  Twice now, it has failed (hung) when doing an update to the Exchange Intelligent Message Filter.  When this happens, it leaves your Exchange server in a state where it doesn't work.  Isn't that great?

Anyway, I reboot the system and Exchange still doesn;t come up correctly.  Turns out, I had to go to services, enable the IISAdmin service (this must have been disabled during the failed update), then I went to a cmd prompt and ran "iisreset".  This seems to have solved the problem.

Reduce SQL Svr instance memory usage

http://msmvps.com/blogs/bradley/archive/2005/02/04/34984.aspx

On our SBS2003 box, we sometimes have sql instances using upwards of 1.5Gb ram.  The machine ram usage goes beyond the available physical ram, and the machine slows to a crawl.

We've used this technique to reduce the sbsmonitoring instance and the ssee instance.

There is also a nice tip there for using taskman from the cmd line to get the sql instance.  Of course Process Explorer also will tell you this info directly.

XenServer 5.6 Realtek 8168/8111 problem

If you are trying to use one of these Realtek NICs and are having trouble with XenServer 5.6 fp1, then this may be your solution.


Link

BES not starting after server reboot

We have BES installed on a SBS2003. When the server reboots, BES does not come up. I believe this has to do with service dependencies. I added a dependency for Router and Dispatcher. I made them depend on the SQL server instance. I'm hoping this will fix the problem. Here is the cmd line I used:

C:\Documents and Settings\avp>sc config "BlackBerry Dispatcher" depend= MSSQL$BLACKBERRY/lanmanworkstation/eventlog/ntlmssp/MSExchangeIS

and

C:\Documents and Settings\avp>sc config "BlackBerry Router" depend= MSSQL$BLACKBERRY/lanmanworkstation/eventlog

3 things to note:

1. There is a space after "depend="

2. when I first used "sc config" I tried to just add the dependency, but this command replaces the dependencies. So I think I have the right dependencies for Router svc...
3. you need to use whatever SQL instance name you have; mine is called MSSQL$BLACKBERRY

When I reboot the server next, I will confirm whether this works or not...

Confirmed.  This did the trick, when the server reboots now, BES comes up functional.

Jira not starting after a server reboot

Had this problem, service dependencies fixed it. Here is the link to the article with the magic...

link

Of course, that article is now gone, but here is the updated gist of it:

I have followed the article Running JIRA Standalone as a Service - which includes mention of adding a dependency.

Other dependencies which already existed were:

• Ancillary Function Driver for Winsock
• TCP/IP Protocol Driver

For others reading this, be careful as setting the dependency from the CMD line overwrites all existing dependencies, so you must specify existing dependencies as well.

An example to add the MS SQL Server service as a dependency and retain the existing dependencies which should already exist is:

sc config JIRA0123456789 depend= MSSQLSERVER/Tcpip/Afd

Also, there may be a lock file (... .lock) that may need to be deleted...

Finally, a script similar to the following running on startup may help with the lock file issue.  The location and name of the file needs to be confirmed.  On our system, the file is called:


.jira-home.lock


and is located in:


D:\Jira41

The script runs on start up and is as follows:

cls
:: this script will remove the lockfile after a reboot; there is a bug in jira 4.0.1 on virtual servers that shut down quicker than regular servers
:: michael trengrove
@echo off

if not exist "C:\Program Files\Atlassian\Application Data\JIRA\.jira-home.lock" (GOTO END) else (net stop "Atlassian JIRA 4.0.1")

:: wait 1 minute for Jira to fully shutdown
PING -n 60 127.0.0.1>nul

if not exist "C:\Program Files\Atlassian\Application Data\JIRA\.jira-home.lock" (GOTO start-jira) else (del "C:\Program Files\Atlassian\Application Data\JIRA\.jira-home.lock")

::wait 10 seconds to restart Jira
PING -n 10 127.0.0.1>nul

:start-jira
net start "Atlassian JIRA 4.0.1"
PING -n 20 127.0.0.1>nul
if exist "C:\Program Files\Atlassian\Application Data\JIRA\.jira-home.lock" (GOTO END) else (goto start-jira)

:END

cls

Schlage lock and Vera

I have yet to figure out how to change the batteries in the (*&(%^ thing without the Vera losing track of it. At this point, when I change batteries, I have to reset the lock to factory defaults before I can get it working on my ZWave network again. Of course to reset it and re-pair it, it has to be removed from the door. Not inconvenient at all...

One thing I did learn, though, is that to reset to factory defaults you only have to disconnect the 9Volt; not the other battery pack too.

Ok, Finally success. It turns out my AA batteries were dead. Apparently they must run the ZWave. (I'm not sure what battery engages the motor.) I never suspected the AA because I had just swapped them out 1 month ago. When I did the battery swap, the lock was no longer paired with Vera, but I didn't have time to screw with it. (Because I figured I would have to remove the lock from the door etc...) All I can figure is that while the lock was not paired, maybe it was using more power trying to get configured or re-synced or something... (Or maybe it was just a bad set of batteries... who knows...)

Once I changed the AA batteries, the lock paired the first try. All is good again... for now.

Ok, time to change the batteries again.  The UI reports battery level for the lock is 1% (!), yet it still seems to work fine...

Anyway, once again, afaik, the 9Volt controls the mechanical motor; the AAs power the ZWave radio.  Now what does the gui report the level of?

Update:  Now I have a battery tester.  The orange light was coming on on the deadbolt when I'd enter a code, so I knew the batteries were low.  I checked the 9V and it reported fine, I checked the AAs and they all reported low.  So I gather the gui shows the level of the AAs.

remote Outlook not connecting with HTTPS over RPC

As a result of the screwing around I did with IIS yesterday, I seemed to have broken the ability of remote clients to connect via outlook.

This was fixed by looking at the RPC virtual dir in IIS. The security no longer had "Integrated Windows Authentication" enabled. Toggling this fixed the issue.

To confirm, before I toggled this, I tried the clients with basic auth (which was enabled on IIS) and that did work. Then, to be more secure, I disabled basic and enabled Integrated on IIS, and reset the clients to use Integrated.

All is good again...