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...

OWA 440 Login Timeout

So I thought I was clear last night. I wasn't. This morning the server wouldn't let anyone log on, and no one could access the website, no one could access OWA. OWA reported "440 Login Timeout". website prompted for user/pass.

There are lots of people with the problem 440 login timeout, but none of the posted solutions worked for me. Eventually, after looking at the Event viewer security log, after I had enabled logon/logoff success/failure auditing, I came to this kb article. Error 5 was the case I was looking at. My server is a SBS2003, so I figured the second part shouldn't matter, but I checked it anyway. The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail was set to 2. I changed it to 0, and rebooted. Like magic, all problems went away.

I did a search on CrashOnAuditFail, and it turns out that if it has a value of 2, only administrators are allowed to log on. Exactly what I was seeing. I have no idea how it got set to 2... Here is the link that describes the CrashOnAuditFail settings

SBS Server 2003 DNS failure (kinda)

Got a call to work on a server. When I started looking, the MMC snap-in wouldn't connect to the DNS server, yet the DNS server service was running, error on dns anap-in: "cannot contact the dns server". dcdiag immediately gave me an error LDAP 58. I couldn't look at anything AD related.

Eventually I read this post:

http://www.eggheadcafe.com/forumarchives/windowsserverdns/nov2005/post25141946.asp

which led me to:

KB 832981 - CrashOnAuditFail

Which doesn't sound related, but I followed the instructions and it worked. Now it is possible that I somehow fixed it another way but who knows, as the last step in the KB article was to reboot...

Anyway hopefully this will help someone... (and me next time)