win32.tex

%%
%%

\chapter{The Windows Version of Bareos}
\label{Win32Chapter}
\label{sec:windows}
\index[general]{Platform!Windows}
\index[general]{Windows}

The Windows version of Bareos is a native Win32 port, but there
are very few source code changes to the Unix code, which means that the
Windows version is for the most part running code that has long proved
stable on Unix systems.

Chapter \nameref{SupportedOSes} shows, what Windows versions are supported.

The Bareos component that is most often used in Windows
is the File daemon or Client program.
As a consequence, when we
speak of the Windows version of Bareos below, we are mostly referring to
the File daemon (client).

Once installed Bareos 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.

\section{Windows Installation}
\label{Windows:Installation}
\label{Windows:Configuration:Files}
\index[general]{Installation!Windows}
\index[general]{Windows!File Daemon!Installation}

Normally, you will install the Windows version of Bareos from the binaries.
The \name{winbareos} binary packages are provided under \url{http://download.bareos.org/bareos/release/latest/windows}.
Additionally, there are \elink{OPSI}{http://www.opsi.org} packages available under \url{http://download.bareos.org/bareos/release/latest/windows/opsi}.

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.
Providing you do not already
have Bareos installed, the installer installs the binaries and dlls in
\directory{C:\Program Files\Bareos} and the configuration files
in \directory{C:\ProgramData\Bareos} (for Windows XP and older: \directory{C:\Documents and Settings\All Users\Application Data\Bareos}).

In addition, the {\bf Start\-{\textgreater}All Programs\-{\textgreater}Bareos} menu item
will be created during the installation, and on that menu, you
will find items for editing the configuration files, displaying
the document, and starting a user interface.

During installation you can decide, what Bareos components you want to install.

Typically, you only want to install the Bareos Client (\bareosFd) and optionally some interface tools on a Windows system.
Normally, we recommend to let the server components run on a Linux or other Unix system.
However, it is possible, to run the \bareosDir, \bareosSd and \bareosWebui on a Windows systems.
You should be aware about following limitations:
\limitation*{Windows}{Windows \bareosDir does not support MySQL database backend}{
When running the \bareosDir on Windows, only PostgreSQL (and SQLite) database backends are supported.
SQLite is best suited for test environments.
}
\limitation*{Windows}{\bareosSd only support backup to disk, not to tape}{
}
\limitation*{Windows}{The default installation of \bareosWebui is only suitable for local access}{%
Normally the \bareosWebui is running on a Apache server on Linux.
While it is possible, to run the \bareosWebui under Apache or another Webserver which supports PHP under Windows,
the configuration shipped the the \package{winbareos} package uses the PHP internal webserver.
This is okay for local access, but not suitable for being accessed via the network.
To guarantee this, it is configured to only listen locally (\url{http://localhost:9100}).
}


\subsection{Graphical Installation}

Here are the important steps.

\begin{itemize}
    \item You must be logged in as an Administrator to the local machine
    to do a correct installation, if not, please do so before continuing.
    \item For a standard installation you may only select the "Tray-Monitor"
    and the "Open Firewall for Client" as additional optional components.
    \begin{center}
    \includegraphics[width=0.8\textwidth]{\idir win-install-1}
    \end{center}

    \item You need to fill in the name of your bareos director in the client configuration
    dialogue and the FQDN or ip address of your client.
    \begin{center}
    \includegraphics[width=0.8\textwidth]{\idir win-install-2}
    \end{center}

    \item Add the client resource to your Bareos Director Configuration and a
    job resource for the client as it is also described in the default bareos-dir.conf
    \begin{center}
    \includegraphics[width=0.8\textwidth]{\idir win-install-3}
    \end{center}
\end{itemize}

\subsection{Command Line (Silent) Installation}

Silent installation is possible since \sinceVersion{general}{Windows!silent installation}{12.4.4}.
All inputs that are given during interactive install can now directly be configured on the
commandline, so that an automatic silent install is possible.

\paragraph{Commandline Switches}

\begin{description}
\item[/?] shows the list of available parameters.
\item[/S] sets the installer to silent. The Installation is done without user interaction.
This switch is also available for the uninstaller.
\item[/CLIENTADDRESS] network address of the client
\item[/CLIENTNAME] sets the name of the client resource
\item[/CLIENTMONITORPASSWORD] sets the password for monitor access
\item[/CLIENTPASSWORD] sets the password to access the client
\item[/DBADMINUSER=user] sets the database admin user, default=postgres. \sinceVersion{general}{Windows Installation!DBADMINUSER}{14.2.1}
\item[/DBADMINPASSWORD=password] sets the database admin password, default=\textit{none}. \sinceVersion{general}{Windows Installation!DBADMINPASSWORD}{14.2.1}
\item[/DIRECTORADDRESS] sets network address of the director for bconsole or bat access
\item[/DIRECTORNAME] sets the name of the director to access the client and of the director to
accessed by bconsole and bat
\item[/DIRECTORPASSWORD] set the password to access the director
\item[/SILENTKEEPCONFIG] keep configuration files on silent uninstall and use exinsting config files during silent install. \sinceVersion{general}{Windows Installation!SILENTKEEPCONFIG}{12.4.4} 
\item[/INSTALLDIRECTOR] install the Bareos Director (and bconsole). \sinceVersion{general}{Windows Installation!INSTALLDIRECTOR}{14.2.1} 
\item[/INSTALLSTORAGE] install the Bareos Storage Daemon. \sinceVersion{general}{Windows Installation!INSTALLSTORAGE}{14.2.1} 
\item[/WRITELOGS] makes also non-debug installer write a log file. \sinceVersion{general}{Windows Installation!WRITELOGS}{14.2.1} 
\item[/D=\path|C:\specify\installation\directory|] (Important: It has to be the last option!)
\end{description}

By setting the Installation Parameters via commandline and using the silent installer,
you can install the bareos client without having to do any configuration after the
installation e.g. as follows:

\footnotesize
\begin{verbatim}
c:\winbareos.exe /S /CLIENTNAME=hostname-fd /CLIENTPASSWORD="verysecretpassword" /DIRECTORNAME=bareos-dir
\end{verbatim}
\normalsize

DBADMINUSER and DBADMINPASSWORD are used to create the bareos
databases. If login is not possible silent installer will abort


\section{Dealing with Windows Problems}
\index[general]{Problem!Windows}
\index[general]{Windows!Dealing with Problems}

\subsection{Antivirus Program}

If you are not using the portable option, and you have
\linkResourceDirective{Dir}{FileSet}{Enable VSS}
(Volume Shadow Copy) enabled in the \bareosDir and you experience
problems with Bareos not being able to open files, it is most
likely that you are running an antivirus program that blocks
Bareos from doing certain operations. In this case, disable the
antivirus program and try another backup.  If it succeeds, either
get a different (better) antivirus program or use something like
\linkResourceDirective{Dir}{Job}{Client Run Before Job}/\linkResourceDirective{Dir}{Job}{Client Run Before Job}
to turn off the antivirus program while
the backup is running.

If turning off anti-virus software does not resolve your VSS
problems, you might have to turn on VSS debugging.  The following
link describes how to do this:
\url{http://support.microsoft.com/kb/887013/en-us}.

\subsection{Enable Debuggging}

In case of problems, you can enable the creation of log files.
For this you have to use the \command{bconsole} \ilink{setdebug}{bcommandSetdebug} command:
\begin{bconsole}{Enable debug}
*<input>setdebug client=bareos-fd level=200 trace=1</input>
Connecting to Client bareos-fd at bareos.example.com:9102
2000 OK setdebug=200 trace=1 hangup=0 tracefile=c:\bareos-fd.trace
\end{bconsole}


\section{Windows Compatibility Considerations}
\label{Compatibility}
\index[general]{Windows!Compatibility Considerations}

\subsection{Exclusively Opened Files}
If you are not using the \nameref{VSS} option and if any applications are running during
the backup and they have files opened exclusively, Bareos 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.  Fortunately, most
Microsoft applications do not open files exclusively so that they can be
backed up.  However, you will need to experiment.  In any case, if Bareos
cannot open the file, it will print an error message, so you will always
know which files were not backed up.
If Volume Shadow Copy Service is enabled, Bareos is able to backing up any
file.

\subsection{Backing up the Windows Registry}
During backup, Bareos doesn't know about the system registry, so you will
either need to write it out to an ASCII file using \command{regedit /e} or use a
program specifically designed to make a copy or backup the registry.


\subsection{Windows Reparse Points}

\sinceVersion{fd}{Windows!Reparse points}{12.4.5}
\index[fd]{Windows!Symbolic links}
\index[fd]{Windows!Junction points}
\index[fd]{Windows!Volume Mount Points (VMP)}

Besides normal files and directories, Windows filesystems also support special files, called "Reparse Points".
Bareos can handle the following types of Reparse points:
\begin{itemize}
    \item Symbolic links to directories
    \item Symbolic links to files
    \item Junction Points
    \item Volume Mount Points
\end{itemize}

The Volume Mount Points are a special case of a Junction Point. To make things easier, in the following when talking about Junction Points, we mean only the Junction Points that are not Volume Mount Points.

The Symbolic Links and the Junction Points are comparable to Symbolic Links in Unix/Linux. They are files that point to another location in the filesystem.

Symbolic Links and Junction Points can be created with the Windows commandline command \command{mklink}.

When doing a directory listing in the commandline (cmd) in Windows, 
it shows the filetypes JUNCTION, SYMLINK or SYMLINKD and the target between the square brackets:

\begin{commands}{special files}
C:\linktest>dir
 Volume in drive C has no label.
 Volume Serial Number is C8A3-971F

 Directory of C:\linktest

08/07/2014  03:05 PM    <DIR>          .
08/07/2014  03:05 PM    <DIR>          ..
08/07/2014  02:59 PM    <SYMLINKD>     dirlink [C:\Program Files\Bareos]
08/07/2014  03:02 PM    <SYMLINK>      filelink [C:\Program Files\Bareos\bareos-dir.exe]
08/07/2014  03:00 PM    <JUNCTION>     junction [C:\Program Files\Bareos]
08/07/2014  03:05 PM    <JUNCTION>     volumemountpoint [\??\Volume{e960247d-09a1-11e3-93ec-005056add71d}\]
               1 File(s)              0 bytes
               5 Dir(s)  90,315,137,024 bytes free
\end{commands}

Symbolic Links. Directory Symbolic Links, and Junctions that are not a Volume MountPoint are treated by Bareos as symbolic links and are backed up and restored as they are, so the object is restored and points to where it pointed when it was backed up.

Volume Mount Points are different. They allow to mount a harddisk partition as a subfolder of a drive instead of a driveletter.

When backing up a Volume Mount Point, it is backed up as directory.

If \configdirective{OneFS} is set to yes (default), the Volume Mount Point (VMP) is backed up as directory but the content of the VMP will not be backed up. Also, the Joblog will contain a message like this:

\begin{bmessage}{Warning on Volume Moint Point and OneFS=yes}
C:/linktest/vmp is a different filesystem. Will not descend from C:/linktest into it.
\end{bmessage}

This is the normal behavior of the \configdirective{OneFS} option. 

If OneFS is set to no, the filedaemon will change into the VMP as if it was a normal directory and will backup all files found inside of the VMP.


\subsubsection{VMPs and VSS Snapshots}

As Virtual Mount Points mounts another Volume into the current filesystem, it is desired that if the content of the VMP will be backed up during the backup (\configline{onefs = no}), we also want to have this volume snapshotted via VSS.

To achieve this, we now automatically check every volume added to the VSS snapshotset if it contains VMPs, and add the volumes mounted by those VMPs to the vss snapshotset recursively.

Volumes can be mounted nested and multiple times, but can only be added to the snapshotset once. This is the reason why the number of vmps can be greater than the number of volumes added for the volume mount points.

The Job Log will show how many VMPs were found like this:

\begin{bmessage}{Volume Mount Points are added automatically to VSS snapshots (if onefs=no)}
Volume Mount Points found: 7, added to snapshotset: 5
\end{bmessage}

Accordingly, if OneFS is set to yes, we do not need to handle Volume Mount Points this way.
If OneFS is set to yes (default), the joblog will contain the following information: 

\begin{bmessage}{Volume Mount Points are ignored on VSS snapshots (if onefs=yes)}
VolumeMountpoints are not processed as onefs = yes.
\end{bmessage}


\subsection{Hard Links}

Windows also supports hard links, even so they are seldom used.
These are treated as normal files and will be restored as individual files (which will not be hardlinks again)


\subsection{FilesNotToBackup Registry Key}
    \label{FilesNotToBackup}

\sinceVersion{fd}{Windows!FilesNotToBackup}{14.2.0}
\index[fd]{Windows!Exclude Files from Backup}

Windows supports a special Registry Key that specifies the names of the files and directories that backup applications should not backup or restore.

The full path to this registry key is 
\registrykey{HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup}

Bareos automatically converts these entries to wildcards which will be automatically excluded from backup.

The backup log shows a short information about the creation of the exludes like this:

\begin{bmessage}{Excludes according to the FilesNotToBackup registry key}
Created 28 wildcard excludes from FilesNotToBackup Registry key
\end{bmessage}

More details can be found if the filedaemon is run in debug mode inside of the \file{bareos-fd.trace} logfile. 
Each entry and the resulting wildcard are logged.

\begin{bmessage}{translation between registry key FilesNotToBackup and Bareos Exclude FileSet}
client-win-fd: win32.c:465-0 (1) "WER" :
client-win-fd: win32.c:482-0         "C:\ProgramData\Microsoft\Windows\WER\* /s"
client-win-fd: win32.c:527-0     ->  "C:/ProgramData/Microsoft/Windows/WER/*"
client-win-fd: win32.c:465-0 (2) "Kernel Dumps" :
client-win-fd: win32.c:482-0         "C:\Windows\Minidump\* /s"
client-win-fd: win32.c:527-0     ->  "C:/Windows/Minidump/*"
client-win-fd: win32.c:482-0         "C:\Windows\memory.dmp"
client-win-fd: win32.c:527-0     ->  "C:/Windows/memory.dmp"
client-win-fd: win32.c:465-0 (3) "Power Management" :
client-win-fd: win32.c:482-0         "\hiberfil.sys"
client-win-fd: win32.c:527-0     ->  "[A-Z]:/hiberfil.sys"
client-win-fd: win32.c:465-0 (4) "MS Distributed Transaction Coordinator" :
client-win-fd: win32.c:482-0         "C:\Windows\system32\MSDtc\MSDTC.LOG"
client-win-fd: win32.c:527-0     ->  "C:/Windows/system32/MSDtc/MSDTC.LOG"
client-win-fd: win32.c:482-0         "C:\Windows\system32\MSDtc\trace\dtctrace.log"
client-win-fd: win32.c:527-0     ->  "C:/Windows/system32/MSDtc/trace/dtctrace.log"
\end{bmessage}

It is possible to disable this functionality by setting the FileSet option \configdirective{AutoExclude} to no.

The JobLog will then show the following informational line:
\begin{bmessage}{AutoExclude disabled}
Fileset has autoexclude disabled, ignoring FilesNotToBackup Registry key
\end{bmessage}

For more details about the Windows registry key see 
\url{http://msdn.microsoft.com/en-us/library/windows/desktop/bb891959%28v=vs.85%29.aspx#filesnottobackup}.

\subsection{Windows dedup support}

\sinceVersion{fd}{Windows!dedupclication}{12.4.5}

   Windows 2012 has dedup support which needs handling.


\subsection{Store all file attributes}

\sinceVersion{fd}{Windows!file attributes}{12.4.5}

   Windows has gathered quite some special specific file
   flags over the years but not all are saved during backup so
   some are never restored by the restore process. The most
   important ones are the ARCHIVE flag which is "misused" by
   some programs for storing some special information. Others
   that are known not to be stored are the COMPRESSED flag which
   means that a restored file looses it and will be restored as
   an uncompressed file.

\subsection{Support for Windows EFS filesystems}

\sinceVersion{fd}{Windows!Encrypted Filesystems (EFS)}{12.4.5}

  Windows has support for a so called EFS
  filesystem. This is an encrypted filesystem, to be able to backup the
  data and to restore it we need to use a special API. With this API you
  in essence export the data on backup and import it on restore. This
  way you never have access to the unencrypted data but just import and
  export the encrypted data. This is the cleanest way of handling
  encryption by just seeing the data as some opaque data and not try to
  do anything special with it.



\section{Volume Shadow Copy Service (VSS)}
\index[general]{Windows!Volume Shadow Copy Service}
\index[general]{Windows!VSS}
\label{VSS}

VSS is available since Windows XP. From the perspective of
a backup-solution for Windows, this is an extremely important step. VSS
allows Bareos to backup open files and even to interact with applications like
RDBMS to produce consistent file copies. VSS aware applications are called
VSS Writers, they register with the OS so that when Bareos wants to do a
Snapshot, the OS will notify the register Writer programs, which may then
create a consistent state in their application, which will be backed up.
Examples for these writers are "MSDE" (Microsoft database
engine), "Event Log Writer", "Registry Writer" plus 3rd
party-writers.  If you have a non-vss aware application a shadow copy is still generated
and the open files can be backed up, but there is no guarantee
that the file is consistent.

Bareos produces a message from each of the registered writer programs
when it is doing a VSS backup so you know which ones are correctly backed
up.

Technically Bareos creates a shadow copy as soon as the backup process
starts. It does then backup all files from the shadow copy and destroys the
shadow copy after the backup process. Please have in mind, that VSS
creates a snapshot and thus backs up the system at the state it had
when starting the backup. It will disregard file changes which occur during
the backup process.

VSS can be turned on by placing an

\index[dir]{Enable VSS}
\index[general]{VSS!Enable}
\begin{verbatim}
Enable VSS = yes
\end{verbatim}

in your FileSet resource.

The VSS aware File daemon has the letters VSS on the signon line that
it produces when contacted by the console. For example:
\begin{verbatim}
Tibs-fd Version: 1.37.32 (22 July 2005) VSS Windows XP MVS NT 5.1.2600
\end{verbatim}
the VSS is shown in the line above. This only means that the File daemon
is capable of doing VSS not that VSS is turned on for a particular backup.
There are two ways of telling if VSS is actually turned on during a backup.
The first is to look at the status output for a job, e.g.:
\footnotesize
\begin{verbatim}
Running Jobs:
JobId 1 Job NightlySave.2005-07-23_13.25.45 is running.
    VSS Backup Job started: 23-Jul-05 13:25
    Files=70,113 Bytes=3,987,180,650 Bytes/sec=3,244,247
    Files Examined=75,021
    Processing file: c:/Documents and Settings/user/My Documents/My Pictures/Misc1/Sans titre - 39.pdd
    SDReadSeqNo=5 fd=352
\end{verbatim}
\normalsize
Here, you see under Running Jobs that JobId 1 is "VSS Backup Job started ..."
This means that VSS is enabled for that job.  If VSS is not enabled, it will
simply show "Backup Job started ..." without the letters VSS.

The second way to know that the job was backed up with VSS is to look at the
Job Report, which will look something like the following:
\footnotesize
\begin{verbatim}
23-Jul 13:25 rufus-dir: Start Backup JobId 1, Job=NightlySave.2005-07-23_13.25.45
23-Jul 13:26 rufus-sd: Wrote label to prelabeled Volume "TestVolume001" on device "DDS-4" (/dev/nst0)
23-Jul 13:26 rufus-sd: Spooling data ...
23-Jul 13:26 Tibs: Generate VSS snapshots. Driver="VSS WinXP", Drive(s)="C"
23-Jul 13:26 Tibs: VSS Writer: "MSDEWriter", State: 1 (VSS_WS_STABLE)
23-Jul 13:26 Tibs: VSS Writer: "Microsoft Writer (Bootable State)", State: 1 (VSS_WS_STABLE)
23-Jul 13:26 Tibs: VSS Writer: "WMI Writer", State: 1 (VSS_WS_STABLE)
23-Jul 13:26 Tibs: VSS Writer: "Microsoft Writer (Service State)", State: 1 (VSS_WS_STABLE)
\end{verbatim}
\normalsize
In the above Job Report listing, you see that the VSS snapshot was generated for drive C (if
other drives are backed up, they will be listed on the \bconsoleOutput{Drive(s)="C"} line.
You also see the
reports from each of the writer program.  Here they all report VSS\_WS\_STABLE, which means
that you will get a consistent snapshot of the data handled by that writer.

\subsection{VSS Problems}
\index[general]{Windows!Problem!VSS}
\index[general]{Windows!VSS!Problem}
\index[fd]{Windows!Problem!VSS}
\index[general]{Problem!Windows!VSS}


If you are experiencing problems such as VSS hanging on MSDE, first try
running {\bf vssadmin} to check for problems, then try running {\bf
ntbackup} which also uses VSS to see if it has similar problems. If so, you
know that the problem is in your Windows machine and not with Bareos.

The FD hang problems were reported with {\bf MSDEwriter} when:
\begin{itemize}
\item a local firewall locked local access to the MSDE TCP port (MSDEwriter
seems to use TCP/IP and not Named Pipes).
\item msdtcs was installed to run under "localsystem": try running msdtcs
under  networking account (instead of local system) (com+ seems to work
better with this configuration).
\end{itemize}


\section{Windows Firewalls}
\index[general]{Firewall!Windows}
\index[general]{Windows!Firewall}

The Windows buildin Firewall is enabled since Windows version WinXP SP2.
The Bareos installer opens the required network ports for Bareos.
However, if you are using another Firewall, you might need to manually open the Bareos network ports.
The \bareosFd listens on 9102/TCP.

\subsection{Network TCP Port}

If you want to see if the File daemon has properly opened the port and is
listening, you can enter the following command in a shell window:

\begin{commands}{}
netstat -an | findstr 910[123]
\end{commands}



\section{Windows Restore Problems}
\index[general]{Problem!Windows Restore}
\index[general]{Windows!Restore Problem}

Please see the \nameref{sec:RestoreOnWindows} chapter for problems
that you might encounter doing a restore.

\section{Windows Backup Problems}
\index[general]{Problem!Windows Backup}
\index[general]{Windows!Backup Problems}

If during a Backup, you get the message:
{\bf ERR=Access is denied} and you are using the portable option,
you should try both adding both the non-portable (backup API) and
the Volume Shadow Copy options to your Director's conf file.

In the Options resource:
\footnotesize
\begin{verbatim}
portable = no
\end{verbatim}
\normalsize

In the FileSet resource:
\footnotesize
\begin{verbatim}
enablevss = yes
\end{verbatim}
\normalsize

In general, specifying these two options should allow you to backup
any file on a Windows system.  However, in some cases, if users
have allowed to have full control of their folders, even system programs
such a Bareos can be locked out.  In this case, you must identify
which folders or files are creating the problem and do the following:

\begin{enumerate}
\item Grant ownership of the file/folder to the Administrators group,
with the option to replace the owner on all child objects.
\item Grant full control permissions to the Administrators group,
and change the user's group to only have Modify permission to
the file/folder and all child objects.
\end{enumerate}

Thanks to Georger Araujo for the above information.

\section{Windows Ownership and Permissions Problems}
\index[general]{Problem!Windows Ownership and Permissions}
\index[general]{Windows!Ownership and Permissions Problems}

If you restore files backed up from Windows to an alternate directory,
Bareos 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 Bareos runs under as a service and 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 {\bf SetACL}, which can be found at
\elink{http://setacl.sourceforge.net/}{http://setacl.sourceforge.net/}.

If you have not installed Bareos while running as Administrator
and if Bareos is not running as a Process with the userid (User Name) SYSTEM,
then it is very unlikely that it will have sufficient permission to
access all your files.

Some users have experienced problems restoring files that participate in
the Active Directory. They also report that changing the userid under which
Bareos (bareos-fd.exe) runs, from SYSTEM to a Domain Admin userid, resolves
the problem.



\hide{
\section{Fixing the Windows Boot Record}
\index[general]{Windows!Fixing the Boot Record}

An effective way to restore a Windows backup is to install Windows on a different
hard drive and restore the backup.  Then run the
recovery CD and run

\begin{verbatim}
diskpart
   select disk 0
   select part 1
   active
   exit

bootrec /rebuldbcd
bootrec /fixboot
bootrec /fixmbr
\end{verbatim}
}

\section{Advanced Windows Configuration}

\subsection{Windows Service}

The \bareosFd (and also the \bareosDir and \bareosSd) is started as a Windows service.

This is configured in the Registry at

\begin{itemize}
\item \path|Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Bareos-fd|
\end{itemize}

You can use the command \command{regedit} to modify the settings.

E.g. to always start Bareos in debug mode,
modify \path|Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Bareos-fd| \path|ImagePath|
from

{
\footnotesize
\begin{verbatim}
"C:\Program Files\Bareos\bareos-fd.exe" /service
\end{verbatim}
}

to

{
\footnotesize
\begin{verbatim}
"C:\Program Files\Bareos\bareos-fd.exe" /service -d200
\end{verbatim}
}

After restarting the service, you will find a file called \path|C:\bareos-fd.trace| which will
contain the debug output created by the daemon.

\subsubsection{Installing multiple Windows filedaemon services}

It is possible to run multiple \bareosFd instances on Windows.
To achieve this, you  need to create a service for each instance, and a configuration file that at least
has a individual fd port for each instance.

To create two bareos-fd services, you can call the following service create calls on the commandline on windows as administrator:

\begin{commands}{}
sc create bareosfd2 binpath="\"C:\Program Files\Bareos\bareos-fd.exe\" /service  -c \"C:\ProgramData\Bareos\bareos-fd2.conf\""  depend= "tcpip/afd"
sc create bareosfd3 binpath="\"C:\Program Files\Bareos\bareos-fd.exe\" /service  -c \"C:\ProgramData\Bareos\bareos-fd3.conf\""  depend= "tcpip/afd"
\end{commands}

This will create two \bareosFd services, one with the name bareosfd2 and the second with the name bareosfd3.

The configuration files for the two services are \file{bareos-fd.conf} and \file{bareos-fd2.conf}, and need to have different network settings.

The services can be started by calling

\begin{commands}{}
sc start bareosfd2
\end{commands}

and

\begin{commands}{}
sc start bareosfd3
\end{commands}


\subsection{Windows Specific Command Line Options}
\index[general]{Windows!File Daemon!Command Line Options}

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 {\bf Bareos} or you must manually edit
the system registry and modify the appropriate entries.

In order to avoid option clashes between the options necessary for {\bf
Bareos} to run on Windows and the standard Bareos options, all Windows
specific options are signaled with a forward slash character (/), while as
usual, the standard Bareos options are signaled with a minus (-), or a minus
minus (\verb:--:). All the standard Bareos options can be used on the Windows
version. In addition, the following Windows only options are implemented:

\begin{description}

\item [/service ]
   Start Bareos as a service

\item [/run ]
   Run the Bareos application

\item [/install ]
   Install Bareos as a service in the system registry

\item [/remove ]
   Uninstall Bareos from the system registry

\item [/about ]
   Show the Bareos about dialogue box

\item [/status ]
   Show the Bareos status dialogue box

\item [/events ]
   Show the Bareos events dialogue box (not  yet implemented)

\item [/kill ]
   Stop any running {\bf Bareos}

\item [/help ]
   Show the Bareos help dialogue box
\end{description}

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 Bareos is installed. However, you may note these options in
some of the .bat files that have been created for your use.