How to perform a knife-edge cutover for BlackBerry Enterprise Server software versions 4.0 and 4.1

Overview

To perform a knife-edge cutover of the BlackBerry Enterprise Server to another computer, complete the following tasks:

  1. Record the appropriate BlackBerry Enterprise Server information.
  2. Set the local permissions on the new BlackBerry Enterprise Server computer.
  3. Move the BlackBerry Configuration Database to the new BlackBerry Enterprise Server.
  4. Stop the BlackBerry services on the existing BlackBerry Enterprise Server computer.
  5. Ensure that the prerequisites are met.
  6. Install the BlackBerry Enterprise Server software on the new computer.

Task 1

Record the appropriate BlackBerry Enterprise Server information.

  1. Open BlackBerry Manager.
  2. Record the name of the BlackBerry Enterprise Server that is being moved, and then close BlackBerry Manager.
  3. In the Microsoft® Windows® Control Panel, go to Administrative Tools > Services.
  4. Right-click BlackBerry Dispatcher, and then click Properties.
  5. Record the user name that is specified in the This account field on the Log On tab.
  6. Close the Control Panel.

Task 2

Set the local permissions on the new BlackBerry Enterprise Server computer. For instructions, see KB02276.
Task 3

Move the BlackBerry Configuration Database to the new BlackBerry Enterprise Server.

Note: If you are running a remote Microsoft® SQL Server™ and you want to continue using it, skip this step. If you are running a local installation of Microsoft® SQL Server™ Desktop Engine (MSDE), download and install MSDE 2000a from the Microsoft Download Center before proceeding with the backup and restore procedure.

Back up the BlackBerry Configuration Database, and then restore it on the new BlackBerry Enterprise Server. For instructions, see KB03112.
Task 4

Stop the BlackBerry Enterprise Server services on the existing BlackBerry Enterprise Server.

  1. On the existing BlackBerry Enterprise Server, in the Control Panel, go to Administrative Tools > Services.
  2. Right-click each BlackBerry Enterprise Server service, and then click Stop.
  3. Once the services are stopped, right-click each service again and set the Startup type to Manual or Disabled. If the original BlackBerry Enterprise Server restarts and the services are still set to Automatic, the Server Routing Protocol (SRP) Authentication Key and SRP Identifier (ID) may be disabled on the new BlackBerry Enterprise Server.
  4. Close the Services window and the Control Panel.

Task 5

Verify that you have the met the prerequisites for installing the BlackBerry Enterprise Server software. For information, see the BlackBerry Enterprise Server for Microsoft Exchange: Installation Guide for the appropriate BlackBerry Enterprise Server software version.
Task 6

Install the BlackBerry Enterprise Server software on the new computer.

Log in to the new computer using the BlackBerry Enterprise Server administration account, and then install the BlackBerry Enterprise Server software version that is running on the existing computer. For example, if the existing computer is running BlackBerry Enterprise Server software version 4.1 Service Pack 1, install BlackBerry Enterprise Server software version 4.1 Service Pack 1 on the new computer. For instructions, see the BlackBerry Enterprise Server for Microsoft Exchange: Installation Guide for the appropriate BlackBerry Enterprise Server software version.

Note: During the installation procedure, make sure to remember the following points:

  • When prompted for a BlackBerry Enterprise Server name, use the same name as the existing BlackBerry Enterprise Server name. This information was recorded in Task 1.
  • If the BlackBerry Configuration Database has been moved (as in Task 2), use the path to the new Microsoft SQL Server as the location of the BlackBerry Configuration Database. If a local installation of MSDE is used on the new BlackBerry Enterprise Server computer, select Local.
  • Do not start the BlackBerry Enterprise Server services for the new BlackBerry Enterprise Server until they are stopped on the existing BlackBerry Enterprise Server computer.

Important: Restarting certain BlackBerry Enterprise Server services will delay email message delivery to BlackBerry smartphones. For more information, see KB04789.

Additional Information

When using BlackBerry Mobile Data System (BlackBerry MDS) Services, you must create a new mdss and mdss_dis database. A knife-edge cutover of the BlackBerry MDS Services is not supported.

Note: MDSS is supported only if the BlackBerry Enterprise Server name is not changed.

If the existing BlackBerry Enterprise Server is removed from the environment, make sure that all software configuration files that are stored on it are moved to either the new BlackBerry Enterprise Server, or to a different location in the environment. Software configuration settings should be modified accordingly.

No Comments Posted in How To
SSH Hack » ESXi 3.5

I have been playing around with ESXi and needed to upload some files via SCP and discovered that SSH is not enabled by default.

Here goes

  1. At the console of the ESXi host, press ALT-F1 to access the console window.
  2. Enter unsupported in the console and then press Enter. You will not see the text you type in.
  3. If you typed in unsupported correctly, you will see the Tech Support Mode warning and a password prompt. Enter the password for the root login.
  4. You should then see the prompt of ~ #. Edit the file inetd.conf (enter the command *vi /etc/inetd.conf*).
  5. Find the line that begins with #ssh and remove the #. Then save the file. If you’re new to using vi, then move the cursor down to #ssh line and then press the Insert key. Move the cursor over one space and then hit backspace to delete the #. Then press ESC and type in :wq to save the file and exit vi. If you make a mistake, you can press the ESC key and then type it :q! to quit vi without saving the file.
  6. Restart host or try kill -HUP `ps | grep inetd`
1 Comment Posted in ESXi, How To, Linux
How fast is your disk?

With a little bit of torturing, and some fun on the way, find out how fast your hard disk drive really is.

Introduction

2-Terabyte hard disk drives are slowly coming to the market, so I suppose we can’t complain that we don’t have enough space to save (the ever increasing amount of) our precious data. But, it’s also a known fact that although disk storage capacities are improving at an impressive rate, disk performance improvements are occurring at a rather slower rate. Unfortunately, larger disk doesn’t always mean faster disk. What follows is an explanation of two techniques for measuring disk performance in Linux.

Methodology

As an example, I’ve tested three different disks, one standard ATA (IDE) drive, and two SCSI disks with different rotational speed:

Disk 1: ATA 120GB, Seagate Barracuda 7200.7 Plus (ST3120026A), 8MB cache, 7200 rpm
Disk 2: SCSI 36GB, Seagate Cheetah 10K.6 (ST336607LC), 8MB cache, 10000 rpm
Disk 3: SCSI 18GB, IBM Ultrastar 36Z15 (IC35L018UCPR15-0), 4MB cache, 15000 rpm

IMPORTANT! When running the below explained benchmarks, your disk should be as idle as possible. Otherwise, you’ll get wrong (worse) numbers. Don’t run any other disk intensive program at the same time when you are running benchmarks. And, BTW, don’t worry about your data, both benchmarks are only reading from disk, meaning, they’re not destructive.

Sequential access

Sequential access is when you’re reading or writing disk blocks in sequential order, that is, one block after another. Rarely will you do exactly that (unless you’re copying raw partitions, of course), but every time you’re moving big files (for example ISO images) around, your disk access pattern comes close to sequential access. This is also where your disk truly shines, because disk head movement is minimal, so you can get high disk transfer speeds.

Measuring sequential disk performance is easy, every modern Linux distribution comes with a little tool called hdparm, which is primarily used to tune and optimize disk parameters, but also has a switch to use it as a simple benchmark tool. Run it like this:

% sudo hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads:  140 MB in  3.02 seconds =  46.28 MB/sec

Substitute /dev/hda with the name of your raw disk device, of course (for example, it might be /dev/sda if you’re using libata, or something else).

It’s impossible to get higher transfer rate from the disk than that (but on that particular disk, computer, and if disk is setup optimally!). hdparm -t is reading the very start of the disk (which is the fastest area of every disk) and with an optimal access pattern. You can’t beat that!

Let’s see what our test disks are made of:

While there is some fluctuation, I wouldn’t say that there are big differences among the disks. But, you probably noticed that the supposedly fastest 15000 rpm disk is slower than the other two. That’s because it’s a quite old disk (from 2002). So there was some improvement in disk transfer speeds through time, after all, but nothing groundbreaking.

Random access

Random access is where you access your disk at random. In that case the disk head moves rapidly from one place to another. Because that involves mechanical operation, this type of access is much slower than sequential access. Unfortunately, many real world workloads involve access patterns that are much closer to random access than sequential access. That’s why I think it’s much more interesting to measure and see how disk behaves under random access pattern, than sequential.

There’s no standard tool to measure the random access time, so I have written a simple utility that you can find attached at the bottom of this article. I’ve named it seeker and it has a simple job: to read small pieces of data from a raw disk device, in a random access pattern. It is important to run it on the whole disk (not on a single partition!) if you want to compare results of your disk with others!

Compile the utility like this:

% gcc -O2 seeker.c -o seeker

or if you’re lazy or don’t have compiler at hand, you can also download the binary below. Then run it like this:

% sudo seeker /dev/hda

Just like hdparm, it needs superuser privileges to access the raw disk device. The output looks like this:

Seeker v2.0, 2007-01-15,
Benchmarking /dev/sda [17501MB], wait 30 seconds..............................
Results: 167 seeks/second, 5.95 ms random access time

Allow seeker to run for 30 seconds (you might hear some ugly noises if your disk doesn’t have so called acoustic management capability or if it’s not turned on), and you’ll get the average number of seeks per second, and calculated random access time of the disk. Now, the utility reads only 512 bytes of data per one read operation, but internal kernel readahead mechanisms translate that to 4096 byte I/O operations. Multiplying 167 with 4096, you can estimate that disk is reading only 668 KB/sec (or you can use iostat utility to monitor that in realtime). And that is true, this is the absolute worst case scenario, and your disk should always perform better than that, in every real scenario. But, compare that with the numbers we got from the sequential case, and you’ll see how rapidly disk performance degraded when the disk arm started moving!

Disk Seeks Per Second

Disk Seeks Per Second

Finally we see some difference among disks, it’s now obvious that disks that are rotating faster are better performers. 15000 rpm SCSI is now on top, it doesn’t matter it’s so old, it leaves the ATA drive far behind.

Disk Random Access Time

Disk Random Access Time

The above numbers are actually the same data presented in another way. Random access time is a metric that represents the typical time it takes disk to go read a random block. If you have disk manufacturers data with you, that time should be close to the sum of the manufacturers average seek time and average latency time. They declare average seek time as a typical time to move head arm from one position to another, and average latency time is time needed for wanted data block to come below the head (disk is constantly rotating, right?). Is the calculation right for your disk?

Conclusion

If you have some older and some newer disk, and run the above tests on them, you’ll soon discover that hard disk performance hasn’t improved much over time. The bigger cache on modern disks helps a little bit, but only on some specific workloads. But, don’t listen to everything I say, run your own tests and report results as a comment below. If we get enough results, I could even summarize them in a useful graph. And, I would really really love to see the numbers for those Western Digital Raptors, is their performance really comparable to the expensive SCSI drives?

Seeker App –> Seeker.c

No Comments Posted in How To
The Apocalypse is coming err.. well not rely

1905_baird_time_stamp

This Friday February the 13th the Unix time stamp will reach 1234567890 witch will be even more monuments then the day the odometer in my car reached 12345 Km. For those who don’t know the Unix time stamper is the number of seconds that have passed since January 1st 1970 take a look for your self Here.

No Comments Posted in How To