Thursday, January 27, 2011

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.

Wednesday, January 26, 2011

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

Tuesday, January 4, 2011

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.