<commit_before>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\label{sec:platform-windows}Microsoft Windows}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{platform-specific information!Windows|(}

Windows is a strategic platform for Condor,
and therefore we have been working toward a complete
port to Windows.
Our goal is to make Condor every bit as capable on Windows as it is on
Unix -- or even more capable.

Porting Condor from Unix to Windows is a formidable task,
because many
components of Condor must interact closely with the underlying operating
system.
Instead of waiting until all components of Condor are running
and stabilized on Windows,
we have decided to make a clipped version of Condor for Windows.
A clipped version is one in which there is no checkpointing
and there are no remote system calls.

This section contains additional information specific to running
Condor on Windows.  Eventually this information will be integrated
into the Condor Manual as a whole, and this section will disappear.
In order to effectively use Condor, first read the overview
chapter (section~\ref{sec:overview})
and the user's manual (section~\ref{sec:usermanual}).
If you will
also be administrating or customizing the policy and set up of Condor,
also read the administrator's manual 
chapter (section~\ref{sec:Admin-Intro}).
After reading these chapters,
review the information in this chapter for
important information and differences when using and administrating
Condor on Windows.
For information on installing Condor for Windows, see
section~\ref{sec:Windows-Install}.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Limitations under Windows}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Windows!release notes}

In general, this release for Windows works the same as the 
release of Condor for Unix.
However, the following items are not supported in this version:

\begin{itemize}

\item The standard job universe is not present.  This means
transparent process checkpoint/migration and remote system calls are
not supported.

\item For \SubmitCmd{grid} universe jobs, the only supported grid type is
\SubmitCmd{condor}.

\item Accessing files via a network share that requires a kerberos ticket
(such as AFS) is not yet supported.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Supported Features under Windows}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Except for those items listed above, most everything works
the same way in Condor as it does in the Unix release.
This release is based on the Condor \VersionNotice\ source tree, and thus the
feature set is the same as Condor \VersionNotice\ for Unix.  
For instance, all of the following work in Condor:
\begin{itemize}

\item The ability to submit, run, and manage queues of jobs running on a
cluster of Windows machines.

\item All tools such as \Condor{q}, \Condor{status}, \Condor{userprio},
are included. Only \Condor{compile} is
\emph{not} included.

\item The ability to customize job policy using ClassAds.
The machine ClassAds contain all the information included in the Unix version,
including current load average, RAM and virtual memory sizes, integer and
floating-point performance, keyboard/mouse idle time, etc.  Likewise, job
ClassAds contain a full complement of information, including system
dependent entries such as dynamic updates of the job's image size and CPU
usage.

\item Everything necessary to run a Condor central manager on Windows.

\item Security mechanisms.

\item Support for SMP machines.

\item Condor for Windows can run jobs at a lower operating system
priority level.
Jobs can be suspended, soft-killed by using a WM\_CLOSE message,
or hard-killed automatically based upon policy expressions.
For example, Condor can automatically suspend a job
whenever keyboard/mouse or non-Condor created CPU activity is detected, and
continue the job after the the machine has been idle for a specified amount
of time.

\item Condor correctly manages jobs which create multiple processes.  For
instance, if a Condor job spawns multiple processes and Condor
needs to kill the job,
all processes created by the job will be terminated.

\item In addition to interactive tools, users and administrators can receive
information from Condor by e-mail (standard SMTP) and/or by log files.

\item Condor includes a friendly GUI installation and set up program,
which can perform a full install or deinstall of Condor.
Information specified by the user in the set up program is stored in the
system registry.  
The set up program can update a current installation with a
new release using a minimal amount of effort.

\item Condor can give a job access to the running user's Registry hive.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{\label{sec:windows-sps}Secure Password Storage}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

In order for Condor to operate properly, it must at times be able to
act on behalf of users who submit jobs.  In particular, this is
required on submit machines so that Condor can access a job's input
files, create and access the job's output files, and write to the
job's log file from within the appropriate security context.  It may
also be desirable for Condor to execute the job itself under the
security context of its submitting user (see
\ref{sec:windows-run-as-owner} for details on running jobs as the
submitting user on Windows).

On Unix systems, arbitrarily changing what user Condor performs its
actions as is easily done when Condor is started with root privileges.
On Windows, however, performing an action as a particular user
requires knowledge of that user's password, even when running at the
maximum privilege level.

Condor on Windows supports the notion of \Term{user privilege switching}
through the use of a secure password store.  Users can provide Condor
with their passwords using the \Condor{store\_cred} tool.  Passwords
managed by Condor are encrypted and stored at a secure location within the
Windows registry.  When Condor needs to perform an action as a
particular user, it can then use the securely stored password to do
so.

The secure password store can be managed by the \Condor{schedd}.  This
is Condor's default behavior, and is usually a good approach in
environments where the user's password is only needed on the
submit machine.
This occurs when users are are not allowed to
submit jobs that run under the security context of the submitting
user.

In environments where users can submit Condor jobs that run using
their Windows accounts, it is necessary to configure a centralized
\Condor{credd} daemon to manage the secure password store.  This makes a
user's password available, via an encrypted connection to the
\Condor{credd}, to any execute machine that may need to execute a job
under the user's Windows account.

The \File{condor\_config.local.credd} example file, included in the<commit_msg>added index entries for the credd<commit_after>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\label{sec:platform-windows}Microsoft Windows}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{platform-specific information!Windows|(}

Windows is a strategic platform for Condor,
and therefore we have been working toward a complete
port to Windows.
Our goal is to make Condor every bit as capable on Windows as it is on
Unix -- or even more capable.

Porting Condor from Unix to Windows is a formidable task,
because many
components of Condor must interact closely with the underlying operating
system.
Instead of waiting until all components of Condor are running
and stabilized on Windows,
we have decided to make a clipped version of Condor for Windows.
A clipped version is one in which there is no checkpointing
and there are no remote system calls.

This section contains additional information specific to running
Condor on Windows.  Eventually this information will be integrated
into the Condor Manual as a whole, and this section will disappear.
In order to effectively use Condor, first read the overview
chapter (section~\ref{sec:overview})
and the user's manual (section~\ref{sec:usermanual}).
If you will
also be administrating or customizing the policy and set up of Condor,
also read the administrator's manual 
chapter (section~\ref{sec:Admin-Intro}).
After reading these chapters,
review the information in this chapter for
important information and differences when using and administrating
Condor on Windows.
For information on installing Condor for Windows, see
section~\ref{sec:Windows-Install}.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Limitations under Windows}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Windows!release notes}

In general, this release for Windows works the same as the 
release of Condor for Unix.
However, the following items are not supported in this version:

\begin{itemize}

\item The standard job universe is not present.  This means
transparent process checkpoint/migration and remote system calls are
not supported.

\item For \SubmitCmd{grid} universe jobs, the only supported grid type is
\SubmitCmd{condor}.

\item Accessing files via a network share that requires a kerberos ticket
(such as AFS) is not yet supported.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Supported Features under Windows}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Except for those items listed above, most everything works
the same way in Condor as it does in the Unix release.
This release is based on the Condor \VersionNotice\ source tree, and thus the
feature set is the same as Condor \VersionNotice\ for Unix.  
For instance, all of the following work in Condor:
\begin{itemize}

\item The ability to submit, run, and manage queues of jobs running on a
cluster of Windows machines.

\item All tools such as \Condor{q}, \Condor{status}, \Condor{userprio},
are included. Only \Condor{compile} is
\emph{not} included.

\item The ability to customize job policy using ClassAds.
The machine ClassAds contain all the information included in the Unix version,
including current load average, RAM and virtual memory sizes, integer and
floating-point performance, keyboard/mouse idle time, etc.  Likewise, job
ClassAds contain a full complement of information, including system
dependent entries such as dynamic updates of the job's image size and CPU
usage.

\item Everything necessary to run a Condor central manager on Windows.

\item Security mechanisms.

\item Support for SMP machines.

\item Condor for Windows can run jobs at a lower operating system
priority level.
Jobs can be suspended, soft-killed by using a WM\_CLOSE message,
or hard-killed automatically based upon policy expressions.
For example, Condor can automatically suspend a job
whenever keyboard/mouse or non-Condor created CPU activity is detected, and
continue the job after the the machine has been idle for a specified amount
of time.

\item Condor correctly manages jobs which create multiple processes.  For
instance, if a Condor job spawns multiple processes and Condor
needs to kill the job,
all processes created by the job will be terminated.

\item In addition to interactive tools, users and administrators can receive
information from Condor by e-mail (standard SMTP) and/or by log files.

\item Condor includes a friendly GUI installation and set up program,
which can perform a full install or deinstall of Condor.
Information specified by the user in the set up program is stored in the
system registry.  
The set up program can update a current installation with a
new release using a minimal amount of effort.

\item Condor can give a job access to the running user's Registry hive.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{\label{sec:windows-sps}Secure Password Storage}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

In order for Condor to operate properly, it must at times be able to
act on behalf of users who submit jobs.  In particular, this is
required on submit machines so that Condor can access a job's input
files, create and access the job's output files, and write to the
job's log file from within the appropriate security context.  It may
also be desirable for Condor to execute the job itself under the
security context of its submitting user (see
\ref{sec:windows-run-as-owner} for details on running jobs as the
submitting user on Windows).

On Unix systems, arbitrarily changing what user Condor performs its
actions as is easily done when Condor is started with root privileges.
On Windows, however, performing an action as a particular user
requires knowledge of that user's password, even when running at the
maximum privilege level.

Condor on Windows supports the notion of \Term{user privilege switching}
through the use of a secure password store.  Users can provide Condor
with their passwords using the \Condor{store\_cred} tool.  Passwords
managed by Condor are encrypted and stored at a secure location within the
Windows registry.  When Condor needs to perform an action as a
particular user, it can then use the securely stored password to do
so.

The secure password store can be managed by the \Condor{schedd}.  This
is Condor's default behavior, and is usually a good approach in
environments where the user's password is only needed on the
submit machine.
This occurs when users are are not allowed to
submit jobs that run under the security context of the submitting
user.

\index{Condor daemon!condor\_credd@\Condor{credd}}
\index{daemon!condor\_credd@\Condor{credd}}
\index{condor\_credd daemon}
In environments where users can submit Condor jobs that run using
their Windows accounts, it is necessary to configure a centralized
\Condor{credd} daemon to manage the secure password store.  This makes a
user's password available, via an encrypted connection to the
\Condor{credd}, to any execute machine that may need to execute a job
under the user's Windows account.

The \File{condor\_config.local.credd} example file, included in the
{'fraction_non_alphanumeric': 0.1170286346659289, 'fraction_numerical': 0.0, 'mean_word_length': 5.144921376965576, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3068556', 'n_tokens_mistral': 3527, 'n_tokens_neox': 3358, 'n_words': 1983}