 
#include "bacula_template.inc" title="Win32 Implementation" num=20

<h1>The Windows Version of Bacula</h1>
<h2>General</h2>
At the current time only the File daemon or Client program
has been tested on Windows. As a consequence, when we speak of the Windows
version of Bacula below, we are referring to the File daemon
only.
<p>
The Windows version of the Bacula File daemon has been tested on 
Win98, WinMe, WinNT, and Win2000 systems.  We have coded to support     
Win95, but no longer have a system for testing.
The Windows version of Bacula is a native Win32 port, but there
are very few source code changes, which means that the Windows version is for
the most part running code that has long proved stable on Unix systems.
When running,
it is perfectly integrated with Windows and displays its icon in the
system icon tray, and provides a system tray menu to obtain additional
information on how Bacula is running (status and events dialog
boxes). If so desired, it can also be stopped by using the system tray
menu, though this should normally never be necessary.
<p>Once installed Bacula normally runs as a system service. This
means that it is immediately started by the operating system when the
system is booted, and runs in the background even if there is no user
logged into the system. 
<h3><a name="installation">Installation</a></h3>
Normally, you will install the Windows version of Bacula from the
binaries.  This install is standard Windows .exe that runs an install
wizard using the NSIS Free Software installer, so if you have 
already installed Windows software, it should be very familiar to
you.
<p>
If you have a previous version Cygwin
of Bacula (1.32 or lower) installed,
you should stop the service, uninstall it, and remove the directory
possibly saving your bacula-fd.conf file for use with the new
version you will install. The new native version of Bacula has
far fewer files than the old Cygwin version.
<p>
Finally, proceed with the installation.
<ul>
 <li>Simply double click on the <b>winbacula-1.xx.0.exe</b> 
     NSIS install icon.  The
     actual name of the icon will vary from one release version to
     another.  <p><img src="win32-nsis.png" border="0" alt="">
          winbacula-1.xx.0.exe
          </li><br>&nbsp;<br>
  <li>Once launched, the installer wizard will ask you if you want
      to install Bacula.
      <p>
      <img src="win32-welcome.png" border="0" alt="">
      </li><br>&nbsp;<br>
  <li>If you proceed, you will be asked to select the components to be
       installed. You may install the Bacula program (Bacula File Service)
       and or the documentation.  Both will be installed in sub-directories
       of the install location that you choose later. The components
       dialog looks like the following:
       <p><img src="win32-pkg.png" border="0" alt=""></li>
       <p>
  <li>Next you will be asked to select an installation directory.
      <p><img src="win32-location.png" border="0" alt="">
      <p>
      </li><br>
   <li>If you are installing for the first time, you will
       be asked if you want to edit the bacula-fd.conf file, and
       if you respond with yes, it will be opened in notepad.
       </li><br>&nbsp;<br>
   <li>Then the installer will ask if wish to install Bacula as a
       service. You should always choose to do so:
      <p><img src="win32-service.png" border="0" alt="">
      <p>
       </li><br>&nbsp;<br>
    <li>If everything goes well, you will receive the following
        confirmation:
      <p><img src="win32-service-ok.png" border="0" alt="">
      <p>
       </li><br>&nbsp;<br>
     <li>Then you will be asked if you wish to start the service.
        If you respond with yes, any running Bacula will be shutdown
        and the new one started. You may see a DOS box momentarily 
        appear on the screen as the service is started. It should
        disappear in a second or two:
      <p><img src="win32-start.png" border="0" alt="">
      <p>
       </li><br>&nbsp;<br>
      <li>Finally, the finish dialog will appear:
      <p><img src="win32-finish.png" border="0" alt="">
      <p>
       </li><br>&nbsp;<br>
</ul>

That should complete the installation process. When the Bacula File Server
is ready to serve files, an icon 
<img src="idle.gif" width="16" height="16" border="0" alt="">
representing a cassette (or tape) will appear in the system tray
<img src="tray-icon.jpg">; right click on it
and a menu will appear.<br>&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;<img src="menu.jpg"><br> 
The <b>Events</b> item is currently unimplemented, by
selecting the
<b>Status</b> item, you can verify
whether any jobs are running or not.
<p>When the Bacula File Server begins saving files, the color of
the holes in the cassette icon will change from white to green         
<img src="running.gif" width="16" height="16" border="0" alt="">, 
and if there is an error, the holes in the cassette icon will change to red
<img src="error.gif" width="16" height="16" border="0" alt="">.
<p>If you are using remote desktop connections between your windows 
boxes, be warned that that tray icon does not always appear.  It will 
always be visible when you log into the console, but the remote 
desktop may not display it.

<h3>Post Installation</h3>
After installing Bacula and before running it, you should check
the contents of <b>c:\bacula\bin\bacula-fd.conf</b> to ensure that
it corresponds to your configuration.

<h3>Uninstalling Bacula</h3>
Once Bacula has been installed, it can be uninstalled using the
standard Windows Add/Remove Programs dialog found on the
Control panel.

<h3><a name="problems">Dealing with Problems</a></h3>
The most likely source of problems is authentication when the Director
attempts to connect to the File daemon that you installed. This can occur
if the names and the passwords defined in the File daemon's configuration
file <b>c:\bacula\bin\bacula-fd.conf</b> on the Windows machine do not
match with the names and the passwords in the Director's configuration
file <b>bacula-dir.conf</b> located on your Unix/Linux server.
<p>More specifically, the password found in the <b>Client</b> resource
in the Director's configuration file must be the same as the password
in the <b>Director</b> resource of the File daemon's configuration 
file. In addition, the name of the <b>Director</b> resource in the
File daemon's configuration file must be the same as the name in
the <b>Director</b> resource of the Director's configuration file.
<p>It is a bit hard to explain in words, but if you understand that
a Director normally has multiple Clients and a Client (or File daemon)
may permit access by multiple Directors, you can see that the names and the
passwords on both sides must match for proper authentication.
<p>One user had serious problems with the configuration file
until he realized that the Unix end of line conventions were used
and Bacula wanted them in Windows format.  This has not been
confirmed though.
<p><p>
Running Unix like programs on Windows machines is a bit frustrating
because the Windows command line shell (DOS Window) is rather
primitive. As a consequence, it is not generally possible to see
the debug information and certain error messages that Bacula 
prints. With a bit of work, however, it is possible. 
When everything else fails and you want to <b>see</b> what
is going on, try the following:
<pre>
   Start a DOS shell Window.

   cd c:\bacula\bin
   bacula-fd -t &gt;out
   type out
</pre>
The <b>-t</b> option will cause Bacula to read the configuration
file, print any error messages and then exit. the <b>&gt;</b> redirects
the output to the file named <b>out</b>, which you can list with the
<b>type</b> command.
<p>
If something is going wrong later, or you want to run <b>Bacula</b>
with a debug option, you might try starting it as:
<pre>
   bacula-fd -d 100 &gt;out
</pre>
In this case, Bacula will run until you explicitly stop it, which will
give you a chance to connect to it from your Unix/Linux server.
<p>
In addition, you should look in the System Applications log on the
Control Panel to find any
Windows errors that Bacula got during the startup process.
<p>
Finally, due to the above problems, when you turn on debugging, and
specify trace=1 on a setdebug command in the Console,        
Bacula will write the debug information to the file <b>bacula.trace</b>
in the directory from which Bacula is executing.

<a name="Compatibility"></a>
<h3>Windows Compatibility Considerations</h3>
If any applications are running during the backup and they have
open files, Bacula will not be able to backup those
files, so be sure you close your applications (or tell
your users to close their applications) before the backup.
<p>
During backup,
Bacula doesn't know about the system registry, so you will
either need to write it out to an ASCII file using <b>regedit /e</b>
or use a program specifically designed to make a copy or
backup the registry.
<p>
In Bacula versions 1.30 and earlier, we used the
Cygwin emulation of Unix open(), read(), write(), ...
calls to access files. This worked pretty well for Win95,
Win98, and WinMe systems, but not very well for the
other systems (NT/2K/XP) because those systems have special
security and ownership information that was not saved. In addition
on the NT/2K/XP systems, older versions of Bacula were not always
able to access all files due to system permissions restrictions.
<p>
As a consequence, in Bacula version 1.31 and later, we use Windows
backup API calls by default.  Typical of Windows, programming these
special BackupRead and BackupWrite calls is a real nightmare of
complications.  The end result gives some distinct advantages and some
disadvantages.

<p>First, the advantages are
that on WinNT/2K/XP systems, the security and ownership information
is now backed up. In addition, with the exception of files in
use by another program (a major disaster for backup programs
on Windows), Bacula can now access all system files.
This means that when you restore files, the security and ownership
information will be restored on WinNT/2K/XP along with the data. 

<p>The disadvantage of the Windows backup API calls is that it
produces non-portable backups. That is files and their data
that are backed up on WinNT using the native API calls
(BackupRead/BackupWrite) cannot be restored on Win95/98/Me or Unix
systems.  In principle, a file backed up on WinNT can be restored on
WinXP, but this remains to be seen in practice (not yet tested).
In addition, the stand-alone tools such as <b>bls</b> and <b>bextract</b> 
cannot be used to retrieve the data for those files because those 
tools are not available on Windows. All restores must use the
Bacula <b>restore</b> command. This restriction is mentioned      
for completeness, but in practice should not create any problems.

<p>As a default, Bacula backs up Windows systems using the Windows
API calls.  If you want to backup data on a WinNT/2K/XP system and
restore it on a Unix/Win95/98/Me system, we have provided a special
<b>portable</b> option that backups the data in a portable fashion by
using portable API calls.  See the 
<a href="dirdconf.html#portable">portable option</a> on the Include
statement in a FileSet resource in the Director's configuration chapter
for the details on setting this option.  However, using the portable
option means you may have permissions problems accessing files, and none
of the security and ownership information will be backed up or restored.
The file data can, however, be restored on any system.

<p>
You should always be able to restore any file 
backed up on Unix or Win95/98/Me to any other system. On some
systems, such as WinNT/2K/XP, you may have to reset the ownership
of such restored files.  Any file backed up on WinNT/2K/XP
should in principle be able to be restored to a similar
system (i.e. WinNT/2K/XP), however, I am unsure of the 
consequences if the owner information and accounts are not
identical on both systems.  Bacula will not
let you restore files backed up on WinNT/2K/XP to any other
system (i.e. Unix Win95/98/Me) if you have used the defaults.

<p>
Finally, if you specify the <b>portable=yes</b> option on the
files you back up. Bacula will be able to restore them on
any other system. However, any WinNT/2K/XP specific security
and ownership information will be lost.
<p>The following matrix will give you an idea of what
you can expect. Thanks to Marc Brueckner for doing the tests:
<p>
<table cellspacing="2" cellpadding="2" border="3">
<tr> <th>Backup OS</th> <th>Restore OS</th> <th>Results</th> </tr>
<tr> <td>WinMe </td> <td>WinMe </td> <td>Works </td> </tr>
<tr> <td>WinMe </td> <td>WinNT </td> <td>Works (SYSTEM permissions) </td> </tr>
<tr> <td>WinMe </td> <td>WinXP </td> <td>Works (SYSTEM permissions) </td> </tr>
<tr> <td>WinMe </td> <td>Linux </td> <td>Works (SYSTEM permissions) </td> </tr>
<tr> <td>&nbsp; </td> <td>&nbsp; </td> <td>&nbsp;</td> </tr>

<tr> <td>WinXP </td> <td>WinXP </td> <td>Works </td> </tr>
<tr> <td>WinXP </td> <td>WinNT </td> <td>Works (all files OK, but got &quot;The data is invalid&quot; message)</td></tr>
<tr> <td>WinXP </td> <td>WinMe </td> <td>Error: Win32 data stream not supported. <td> </td> </tr>
<tr> <td>WinXP </td> <td>WinMe </td> <td>Works if <b>Portable=yes</b> specified during backup.</td></tr>
<tr> <td>WinXP </td> <td>Linux </td> <td>Error: Win32 data stream not supported. <td> </td> </tr>
<tr> <td>WinXP </td> <td>Linux </td> <td>Works if <b>Portable=yes</b> specified during backup.</td></tr>
<tr> <td>&nbsp; </td> <td>&nbsp; </td> <td>&nbsp;</td> </tr>

<tr> <td>WinNT </td> <td>WinNT </td> <td>Works </td> </tr>
<tr> <td>WinNT </td> <td>WinXP </td> <td>Works </td></tr>
<tr> <td>WinNT </td> <td>WinMe </td> <td>Error: Win32 data stream not supported.</td> </tr>
<tr> <td>WinNT </td> <td>WinMe </td> <td>Works if <b>Portable=yes</b> specified during backup.</td></tr>
<tr> <td>WinNT </td> <td>Linux </td> <td>Error: Win32 data stream not supported.</td> </tr>
<tr> <td>WinNT </td> <td>Linux </td> <td>Works if <b>Portable=yes</b> specified during backup.</td></tr>
<tr> <td>&nbsp; </td> <td>&nbsp;</td> <td>&nbsp;</td> </tr>

<tr> <td>Linux </td> <td>Linux </td> <td>Works </td> </tr>
<tr> <td>Linux </td> <td>WinNT </td> <td>Works (SYSTEM permissions)</td></tr>
<tr> <td>Linux </td> <td>WinMe </td> <td>Works </td> </tr>
<tr> <td>Linux </td> <td>WinXP </td> <td>Works (SYSTEM permissions) </td> </tr>
</table>

<h3>Windows Firewalls</h3>
If you turn on the firewalling feature on Windows (default in WinXP SR2),
you are likely to find that the Bacula ports are blocked and you cannot
communicated to the other daemons.
This can be deactivated through the <b>Security Notification</b> dialog,
which is apparently somewhere in the <b>Security Center</b>. I don't have
this on my computer, so I cannot give the exact details.
<p>
The command:
<pre>
netsh firewall set opmode disable
</pre>
is purported to disable the firewall, but this command is not accepted
on my WinXP Home machine.

<h3>Windows Disaster Recovery</h3>
We don't currently have a good solution for disaster recovery on 
Windows as we do on Linux. The main piece lacking is a Windows boot
floppy or a Windows boot CD. Microsoft releases a Windows Pre-installation 
Environment (<b>WinPE</b>) that could possibly work, but we have
not investigated it.  This means that until someone figures out the
correct procedure, you must restore the OS from the installation disks,
then you can load a Bacula client and restore files.  Please
don't count on using <b>bextract</b> to extract files from your
backup tapes during a disaster recovery unless you have backed up
those files using the <b>portable</b> option. <b>bextract</b> does 
not run on Windows, and the normal way Bacula saves files using
the Windows API prevents the files from being restored on a Unix
machine. Once you have an operational Windows OS loaded, you can
run the File daemon and restore your user files.
<p>
Please see <a href="rescue.html#Win32">
Disaster Recovery of Win32 Systems</a> for the latest suggestion,
which looks very promising.

<p>It looks like Bart PE Builder, which creates a Windows PE
(Pre-installation Environment) Boot-CD, may be just what is needed to
build a complete disaster recovery system for Win32. This distribution
can be found at <a href="http://www.nu2.nu/pebuilder/">http://www.nu2.nu/pebuilder/
</a>.

<h3>Windows Ownership and Permissions Problems</h3>
If you restore files backed up from WinNT/XP/2K to an alternate
directory, Bacula may need to create some higher level directories
that were not saved (or restored). In this case, the File daemon 
will create them under the SYSTEM account because that is the
account that Bacula runs under as a service. As of version
1.32f-3, Bacula creates these files with full access permission.
However, there may be cases where you
have problems accessing those files even if you run as
administrator. In principle, Microsoft supplies you with the way to
cease the ownership of those files and thus change the permissions.
However, a much better solution to working with and changing
Win32 permissions is the program <b>SetACL</b>, which can be
found at <a href="http://setacl.sourceforge.net/">http://setacl.sourceforge.net/
</a>.

<h4>Manually resetting the Permissions</h4>
<p>
The following solution was provided by Dan Langille &lt;dan at langille in the dot org domain&gt;.
The steps are performed using Windows 2000 Server but they should apply to most
Win32 platforms.  The procedure outlines how to deal with a problem which arises
when a restore creates a top-level new directory.  In this
example, "top-level" means something like <b>c:\src</b>, not <b>c:\tmp\src</b>
where <b>c:\tmp</b> already exists.  If a restore job specifies / as the 
<b>Where:</b> value, this problem will arise.

<p>
The problem appears as a directory which cannot be browsed with Windows Explorer.
The symptoms include the following message when you try to click on that directory:

<p align="center">
<img src="access-is-denied.jpg" border="0" alt="directory is not accessible"
     width="188" height="126">
</p>

<p>
If you encounter this message, the following steps will change the permissions
to allow full access.

<ol>
<li>right click on the top level directory (in this example, <b>c:/src</b>) and
    select <b>Properties</b>.
<li>click on the Security tab.
<li>If the following message appears, you can ignore it, and click on <b>OK</b>.
<p align="center">
<img src="view-only.jpg" border="0" alt="You only have permission to view the 
current security information on directory" width="425" height="119">
</p>
<p>
You should see something like this:

<p align="center">
<img src="properties-security.jpg" border="0" alt="security properties tab"
     width="367" height="443">
<li>click on Advanced
<li>click on the Owner tab
<li>Change the owner to something other than the current owner (which 
is <b>SYSTEM</b> in this example as shown below).
<p align="center">
<img src="properties-security-advanced-owner.jpg" border="0" alt="Access Control Settings for directory"
     width="485" height="443">
<li>ensure the "Replace owner on subcontainers and objects" box is 
    checked
<li>click on OK
<li> When the message "You do not have permission to read the contents 
of directory "c:\src\basis.  Do you wish to replace the directory 
permissions with permissions granting you Full Control?", click on 
Yes.

<p align="center">
<img src="confirm.jpg" border="0" alt="Security permissions"
     width="668" height="139">

<li>Click on OK to close the Properties tab
</ol>

<p>
With the above procedure, you should now have full control over 
your restored directory.


<h3>Backing Up the WinNT/XP/2K System State</h3>
A suggestion by Damian Coutts <dcoutts at voip dot com do au> using Microsoft's 
NTBackup utility in conjunction with Bacula should permit a full restore
of any damaged system files on Win2K/XP. His
suggestion is to do an NTBackup of the critical system state prior to
running a Bacula backup with the following command:
<pre>
ntbackup backup systemstate /F c:\systemstate.bkf
</pre>
The <b>backup</b> is the command, the <b>systemstate</b> says to backup
only the system state and not all the user files, and the
<b>/F c:\systemstate.bkf</b> specifies where to write the state file.
this file must then be saved and restored by Bacula.
<p>
To restore the system state, you first reload a base operating system
if the OS is damaged, otherwise, this is not necessary, then
you would use Bacula to restore all the damaged or lost user's files and to
recover the <b>c:\systemstate.bkf</b> file. Finally if there 
are any damaged or missing system files or registry problems, you
run <b>NTBackup</b>
and <b>catalogue</b> the system statefile, and then select it for restore.
The documentation says you can't run a command line restore of the systemstate.
<p>
To the best of my knowledge, this has not yet been tested. If you test it,
please report your results to the Bacula email list.

<h2>Windows Considerations for Filename Specifications</h2>
Please see the
<a href="dirdconf.html#win32">Director's Configuration chapter</a> of this manual
for important considerations on how to specify Windows paths in
Bacula FileSet Include and Exclude directives.


<h3>Command Line Options Specific to the Bacula Windows File Daemon (Client)</h3>
These options are not normally seen or used by the user, and are
documented here only for information purposes. At the current time,
to change the default options, you must either manually run <b>Bacula</b>
or you must manually edit the system registry and modify the appropriate
entries.
<p>
In order to avoid option clashes between the options necessary for
<b>Bacula</b> to run on Windows and the standard Bacula options,
all Windows specific options are signaled with a forward slash character (/),
while as usual, the standard Bacula options are signaled with a minus (-),
or a minus minus (--).  All the standard Bacula options can be used on
the Windows version. In addition, the following Windows only options are
implemented:
<dl>
        <dt>/servicehelper  </dt>  <dd>Run the service helper application
                                 (don't use this it is deprecated.).</dd>
        <dt>/service</dt>  <dd>Start Bacula as a service </dd>
        <dt>/run    </dt>  <dd>Run the Bacula application</dd>
        <dt>/install</dt>  <dd>Install Bacula as a service in the system registry</dd>
        <dt>/remove </dt>  <dd>Uninstall Bacula from the system registry</dd>
        <dt>/about  </dt>  <dd>Show the Bacula about dialogue box</dd>
        <dt>/status </dt>  <dd>Show the Bacula status dialogue box</dd>
        <dt>/events </dt>  <dd>Show the Bacula events dialogue box (not
                            yet implemented)</dd>
        <dt>/kill   </dt>  <dd>Stop any running <b>Bacula</b></dd>
        <dt>/help   </dt>  <dd>Show the Bacula help dialogue box</dd>
</dl>
It is important to note that under normal circumstances the user should never
need to use these options as they are normally handled by the system automatically
once Bacula is installed. However, you may note these options in
some of the .bat files that have been created for your use.

<h3>Shutting down Windows Systems</h3>
Some users like to shutdown their windows machines after a backup
using a Client Run After Job directive. If you want to do something
similar, you might take the shutdown program from the                
<a href="http://www.apcupsd.com">apcupsd project</a> or one from the
<a href="http://www.sysinternals.com/ntw2k/freeware/psshutdown.shtml">
Sysinternals project</a>.
 

<page_prev name="What to do when Bacula crashes (Kaboom)" url="kaboom.html">
<page_next name="Disaster Recovery Using Bacula" url="rescue.html">
