All RouterBOARD models except 230:

115200bit/s, 8 data bits, 1 stop bit, no parity, flow control=none by default.

RouterBOARD 230 parameters are:

9600bit/s, 8 data bits, 1 stop bit, no parity, hardware (RTS/CTS) flow control by default.

Install FreeFTPd on a server or workstation. Run FreeFTPd and create a user through the users tab. Change it’s home directory to a directory where you want the back-ups tob e placed.

Go to the SFTP tab, check the Listen address, and change the SFTP root directory to the firectory where you want the back-ups to be placed.

Click the Start button on the SFTP tab.

Go to your CUCM. Navigate to the Cisco Disaster Recovery System, and log in.

Navigate to Backup – Backup device.

Add New. Choose a Backup device name, choose Network Directory, and fill in the server name (IP) of the SFTP server, path = /, username and password of the newly created SFTP user. Choose the number of backups to store on the Network Directory, and click Save. If the backup location is valid the status at the top of the page will tell you it could access the network directory succesful.

Navigate to Backup – Scheduler

Add new.

Choose a Schedule Name, the features you want to include in the back-up, the starting date and time, and the frequency. Press Save and then Press Enable Schedule.

Just for sure you can test your back-up configuration by manually creating a back-up.

Navigate to Backup – Manual Backup.

Choose a Schedule Name, the features you want to include in the back-up, and press Start Backup. Your manual back-up will begin, check back in a couple of minutes if your back-up job went succesful.

-          Create a config file in /etc/samba for the recycle bin config. (I created /etc/samba/rb.conf)
-          Place the following config into the file:                       

##Recycle Bin Configuration File##

name = Recycle Bin
mode = KEEP_DIRECTORIES|VERSIONS|TOUCH
maxsize = 0
exclude = *.tmp|*.temp|*.o|*.obj|~$*|*.~??|*.log|*.trace
excludedir = /tmp|/temp|/cache
noversions = *.doc|*.ppt|*.dat|*.ini

-          Edit your Samba configuration file (/etc/samba.smb.conf).
-          Add the following lines to the share(s) you want to have the recycle bin functionality: 

vfs object = recycle
config-file = /etc/samba/recycle.conf
recycle:repository = Recycle Bin
recycle:keeptree = Yes
recycle:versions = Yes 

-          Restart Samba (“/etc/init.d/samba restart” or “service samba restart”)
-          It could be that you first need to delete a file before the recycle bin folder will show up.

There are lots of options to fine tune to your needs! 

I will be making sort of a todo-list that I can look back at when installing a Microsoft Exchange 2010 server in the future:

This website helped me rooting my HTC and applying a custom ROM on it:

TheUnlockr.com

- To apply a user “Send As” permissions, the user also needs to have “Send on behalf” permissions on the mailbox.
- A mailbox that is hidden from the Exchange Address List can’t be used for a user to “Send As”.
- Exchange updates its permissions like “Send As” permissions every 120 minutes only. This means it could take 2 hours before your “Send As” permissions are configured. There are people saying that an Information Store restart would force the update of permissions, however there is no proof that this works.

Because most people today use Outlook 2007 with cached RPC over HTTP, the “Exchange Address List” won’t be updated directly when creating new users. This also means it’s not directly possible to use the newly created mailbox to send as this mailbox. Turning of caching will show up the newly created mailbox and enable the functionality to send as this mailbox.

I will explain how to configure icons for your nagios map:

By default Nagios will show any icons as a question mark logo, known as unknown.gif and unknown.gd2 in your filesystem.
You can define your own icons by downloading icon packs for Nagios or just creating your own icons.
I don’t need to explain how to create .png files and how to crop images to the best size on your Nagios map (40*40 pixels), however creating .gd2 files will be a little bit different (pretty easy however).

Icons used by Nagios will be put into the following directory:

/usr/local/nagios/share/images/logos 

You have to create a config file for configuring icons on specified hosts or you can just add the icon info in your host definitions. When using a specific config file for your icons, it’s best to create a hostextinfo.cfg file in /usr/local/nagios/etc/objects (where all your monitored host config files resign) and add a line specifying the path of the hostextinfo.cfg file in your nagios.cfg file (nagios.cfg will tell nagios what config files to load at startup/reload).
When you have created the hostextinfo.cfg file (depends on how you named it ofcourse) open hostextinfo.cfg with your favorite editor and use the following config to configure the icons for your hosts:

define hostextinfo{
                host_name                        [one or multiple hosts, separated by a ',']
                # notes_url                        http://webserver/hostinfo.pl?host=you_can_edit_this
                icon_image                        hosts.png
                icon_image_alt 0             hosts
                vrml_image                       hosts.png
                statusmap_image           hosts.gd2
                # 2d_coords                      100,250
                # 3d_coords                      100.0,50.0,75.0
                }

You could also just add the following info in your host definitions, so you would get an entry like this: 

define host{
                use                                        linux-server
                host_name                        [hostname]
                parents                                [parent name]
                alias                                       [alias]
                address                                192.168.*.*
                hostgroups                        linux-servers
                icon_image                        [image.png]
                icon_image_alt                [image]
                vrml_image                       [image.png]
                statusmap_image           [image.gd2]
}

When you want to create your own icons you need the pngtogd2 utility, that is distributed as part of the libgd-tools package in Debian and Ubuntu.

apt-get install libgd-tools

when you created some custom .png files, upload them to your server, and use the following command to make a copy of the specified .png file and automatically create a .gd2 file: 

pngtogd2 [.png file] [use the same name and just put .gd2 at the end] cs 1

When using this command, you will notice you just created a .gd2 file for your custom .png file.
Afterwards you will get something like this:

Pros:

• Free.
• Back-up at the top layer, you can restore a back-up to another ESX(i) server without any problems and without the need to manually creating a second VM or anything.

Cons:

• If using the script for exchange, it’s not possible to restore specific e-mails or users. You could restore a back-up next to the “original” VM, and restore e-mail or users, however that won’t be an efficient way of a restore.
• Had some problems with using compression. It’s no problem using compression with the script, worked like a charm. However I wasn’t able to restore the VM. I’m sure I’m doing something wrong. Couldn’t figure it out in the spare time I had. Will get into it, and update this post with my findings.
• Using compression will use pretty some CPU resources. I personally don’t mind this, because my experience with Virtualization servers are that the CPU isn’t used that much. Most of the time the limit of a Virtualization Server is reached by the amount of memory in the Virtualization Server.
• When using compression to save space on your back-up volume, you will need enough space for the script to store the uncompressed back-up. The script will clone the VM(s) and put them on the back-up volume. When cloning is complete the script will compress the newly created uncompressed clone. When a second clone (compressed) is created from the first (uncompressed) clone, the uncompressed clone will be removed and the compressed clone will stay at your given back-up location.

I won’t get into the installation or anything of the back-up script, because there’s a great how-to at the VMWare thread from the actual owner of the script.

Check this link for the script itself and some FAQs and how-to for using the script

There’s also a thread with a restore script for restoring back-ups made with the back-up script. This is just a script to automate things. You could also just restore manually.

Check this link for the restore script

Something the thread lacked (or I didn’t saw this) was some performance data. I did some testing with offline and live back-ups and the following were the results:
(Just for the record, I will state my ESXi config because the performance data can be different on ESX(i) configurations with different hardware)

• ASUS P5Q-VM Mainboard
• Intel Q6600 Core 2 Quad
• 8GB PC6400 DDR2 Kingston memory
• Intel PRO 1000PT Network adapter
• 3WARE 9650SE-2LP
• 2x 1TB Samsung Spinpoint F1 HD103UJ drives for the 3WARE RAID
• 1x 1TB Samsung Spinpoint F1 HD103UJ drive
• 1x old SATA1 drive for testing purposes

I made back-ups from VMs on the third SATA2 drive (no raid) to the fourth drive (SATA1 no raid), and restored back to the SATA2 (no raid) drive because of space limitation on the RAID configuration.

ESXi CPU usage; (7 VMs running) +/- 350 Mhz = 5%
ESXi CPU usage; during backup/restore +/- 800 Mhz = 10%
ESXi CPU usage; during backup compressing/restore uncompressing +/- 2600 Mhz = 30%

I tested the scripts only with one VM for now. It was an Ubuntu Nagios VM with one VHDD (+/-10GB)

ESXi backup uncompressed; 2,9 mins cloning disk, 4 mins total
ESXi backup compressed; 2,9 mins cloning, 19 mins compressing, 22 mins total.

The compression was nice, the back-up was 1 GB after compression. 10% of the original size. However this can differ for each VM.

ESXi restore uncompressed; 3 mins total
ESXi restore compressed; Couldn’t get it to work for now, however, I timed uncompression, it was 6 mins, and the move from the SATA1 “backup” drive to the SATA2 “operational” drive was about 1 min.

If you could do some guessing, you could say:

• 10GB VM = 4 minutes
• 50GB VM = 20 minutes
• 100GB VM = 40 minutes
• 200 GB VM = 80 minutes (1 hour and 20 minutes)
• 250 GB VM = 100 minutes (1 hour and 40 minutes)

Note: between offline back-up and live back-up is no difference in performance or anything. Your VM can stay on while processing the live back-up. I did not notice any delays on the VM while doing a live back-up, however, my testserver is just a Nagios Monitoring server
When making a live back-up, your ESX(i) server will create a live snapshot and the script will use the snapshot to create the back-up. Afterwards the snapshot will be deleted by the script.

The tests I made are pretty basic. This is the first part of this post. I will check the problems I had while manually restoring compressed back-ups. I will update this post when I have the time to test scripts some more!

UPDATE:

I found out that the default config isn’t good enough for (most) Exchange servers. The ghettoVCB script will attempt to shutdown your VM(s) using the installed VMWare Tools. It will then check for 5 minutes (5 times every 60 seconds) if the VM is shut down, and perform the back-up. If the server isn’t offline after 5 minutes (5 checks), the script will ignore the specific VM.
My exchange server (and pretty much every Exchange server I think) won’t make it to shutdown in 5 minutes. My exchange takes about 10 minutes to shutdown.

I changed  the “POWER_DOWN_TIMEOUT=*” value from it’s default (5) to 15, allowing every VM to have a shutdown time of 15 minutes.

This is what was needed to configure a RouterOS based router to accept a PPTP Client session:

1. Add a user

CLI:

# /ppp secret
# add name=[testuser] password=[testpassword] service=pptp 

GUI:

• Login using Winbox.
• Go to PPP – Secrets
• Press “+” to add a user.
• Configure a “Name” and a “Password”.
• Use the Service Dropdown to select “PPTP”.

2. Enable the PPTP Server

CLI:

# /interface pptp-server server
# set enabled=yes

GUI:

• Go to PPP – Interface
• Press “PPTP Server” button.
• Enable the PPTP Server.

The part where you select that the user is only for the PPTP service is optional, however it is slightly more secure to enable it only for PPTP.

3. Make sure your firewall accepts TCP 1723/GRE

CLI:

/ip firewall filter
add chain=input protocol=tcp dst-port=1723 action=accept
add chain=input protocol=gre action=accept

GUI:

• Go to IP – Firewall
• Check you filter rules for accepting TCP 1723 and GRE protocol
• If your mikrotik has no specific entries for accepting the above, create two rules:
  • Chain: input, Protocol: tcp, Dst. Port: 1723, Action: accept
  • Chain: input, Protocol:gre, Action: accept

Because I insist throwing all monitoring traffic over an Encrypted Tunnel, I thought about letting the Nagios Server log in as a PPTP Client onto the WSBS2K3.

I did the following the configure everything for the above:

• Created a Service account on the SBS2K3 with VPN login permissions.
• Installed PPPd on the Nagios Server.
• Created a new PPTP VPN Tunnel using Webmin (PPTP VPN Client module will be available after installing PPPd and refreshing the modules in Webmin).
• Created a route for my Nagios Server that it can access the SBS2K3 server for monitoring.

I will give you an example to make it more clear to understand:

Let’s say your Remote Server has public ip 1.1.1.1 and it’s internal IP is 192.168.2.10.

You will have to do the following on your Nagios Server:

• Open a SSH session.
• Execute the following command to install PPPd: 

# apt-get install pppd

• Make sure you have webmin installed on your Linux (Nagios) server. If you don’t have Webmin installed, check http://www.webmin.com/deb.html for a tutorial how to install Webmin (Webmin will always come in handy, so don’t hesitate to install Webmin).
• Open the webmin console of your Nagios Server (https://[Local Nagios IP]:10000)
• Go to “Networking” – “PPTP VPN Client”
• Add a new PPTP VPN Tunnel
• Make sure the PPTP Tunnel is configured like beneath.

• Create the tunnel

You can test if the tunnel will be created successful by choosing your newly created Tunnel and pressing “Connect to:” on the left side of the PPTP VPN Client screen.

When the PPTP VPN session is enabled successfully, you only need to add a route so Nagios knows how to reach the Remote Server. The command for adding a route to use in this example is:

# route add -net 192.168.2.0 netmask 255.255.255.0 dev ppp0

This command will make sure that the whole 2.* range is available through the PPP0 interface.

You can also automate the establishment of the tunnel and the route. To let the Nagios Server establish the PPTP Tunnel at boot you can configure the option in your Nagios Webmin PPTP Client Console to connect at boot.
For the route you can edit the Defined Tunnel, and add the above line into the “Other route commands” field of your PPTP VPN tunnel options.

This way your PPTP Tunnel will automatically be established on a boot of the Nagios Server and the route will automatically be added after establishing the PPTP Tunnel.