Windows Security?

This past week I was remotely preparing a customer’s server for induction into our Managed Services offering at ClearPointe.  This process sometimes includes the need to copy files from one of our servers in Little Rock to the remote server.  The server that I was remoted into was running Windows Server 2008 which, by default, with the introduction of User Access Control (UAC) and other features, is more secure than any previous Microsoft operating system….but I think Microsoft might want to rethink the situation that I am about to describe! 

From within an RDP (Remote Desktop Protocol) session on the remote server, I accessed our server in Windows Explorer via UNC path, located the file that I needed to copy to the remote server, right-clicked and selected the Copy option from the menu.  I then navigated to the root of the C: drive on the remote server, which was where I wanted to paste the file.  I right-clicked and selected Paste from the menu…but received the warning dialog box below.

Now, I understand that it can be dangerous to copy and paste certain remote files to a server and such action is oftentimes a sign of malicious activity, but where is the “security” in telling me that I do not have permission to copy files to a particular location over the network but can paste into the Documents folder and then move it to the original desired location?  I guess it could deter a malicious individual if said individual just could not wait the additional 10 seconds that it would take to get his package to the desired location!

Windows Server 2008 Task Scheduler

We recently performed an upgrade on one of the applications that we use to monitor and manage client servers and devices.  As a part of the upgrade  process, we decided to move the application from servers running Windows Server 2003 to new virtual servers running Windows Server 2008.   The application is configured with a series of tasks that run each day during the early morning hours.  The tasks run under an Active Directory user account created solely for the purpose of running these tasks and with only the level of privilege required to perform this action.

After the upgrade it was discovered that the tasks were no longer running.  I began to troubleshoot the problem.  From within the application, I could right-click on a task and select to run a test job from the pop-up menu.  The task completed successfully.  If I selected the option to start the job in the context that it was to run each night, it failed consistently.  So why were the test jobs succeeding when the actual tasks were failing?  I turned to good, old Google and quicky found the root cause of the problem.

I discovered that tasks run in Windows Server 2008’s Task Scheduler, by default, run only when the user is logged onto the server.  This was not the case with Scheduled Tasks in Windows Server 2003.  To remedy the problem, I accessed Task Scheduler on the new server, right-clicked on each task and selected Properties from the pop-up menu.  On the General tab of the task’s properties, I selected the Run whether user is logged on or not option as shown below, and then clicked the OK button.  Now the tasks run nightly as expected.

Task Properties in Windows Server 2008

Although this subtle change in the way tasks are run in Windows Server 2008 is an improvement from a security standpoint, it can cause some head scratching if you are unaware of the change.  I hope this post saves saves some administrators a little head scratching.