Thursday, August 27, 2009

Exchange 2007 and Windows 2008: Online Exchange Backup

Read this is article http://theessentialexchange.com/blogs/michael/archive/2009/01/26/exchange-2007-and-windows-2008-online-exchange-backup-part-6-of-7.aspx

Using Windows Server Backup and the Diskshadow for Hyper-V backup

Read the article http://searchstorage.techtarget.com.au/articles/34981-Using-Windows-Server-Backup-and-the-Diskshadow-for-Hyper-V-backup and also this http://technet.microsoft.com/de-de/library/cc772172%28WS.10%29.aspx

Example: (from http://serverfault.com/questions/55789/command-line-backup-of-running-hyper-v-images-using-volume-shadow-copies-vss-an)

Below are sample scripts used to backup Hyper-V using VSS to create a snapshot. Guest operating systems that do not support VSS will be put into a saved state during the snapshot period.
This sample backs up images located on the E:\VS directory to a local directory at F:\VS Backups. These locations will need to be adjusted to fit your needs. For each source drive, an additional volume will need to be added to the VSS snapshot.
Documentation on the diskshadow.exe command is available on Technet.
Copy each of these three files into a directory and run HyperVBackup.cmd.

HyperVBackup.cmd:
-----------------
REM Use the diskshadow command to support "live" Hyper-V backup
REM though VSS
diskshadow /s diskshadow_script.txt > HyperVBackup_LOG.txt

REM Remove CAB files which are generated to support the exporting
REM of disk shadow copies (not required here)
del *.cab /Q

iskshadow_script.txt:
---------------------
# Remove any existing shadow copies from crashed or errored scripts
# WARNING: this will conflict with other backup software if running
# at the same time.
delete shadows all

# Use a persistent context so we can "map" a drive
set context persistent

# Log everything
set verbose on

# ***TODO*** Change this drive letter to match the location of your
# VHD files
add volume E: alias HyperV1

# Add additional volumes if needed
#add add volume H: alias HyperV2

# Create the shadow copy
create

# Expose each shadowed volume as a drive
# ***TODO*** Make sure the exposed drive letter is available and used
# in the backup script
expose %HyperV1% S:

# Expose additional volumes as needed
#expose %HyperV2% T:

# Execute the backup script (robocopy)
exec HyperVBAckup_exec.cmd

# clean up the shadow copy images
delete shadows all

HyperVBackup_exec.cmd:
----------------------
REM This is the script to perform the actual copy of the files

REM Use robocopy with the source set to the expose shadow drives
REM The drives are read-only, so don't try to reset the archive bit
REM **TODO** Set the destination location for the backups

robocopy S:\VS "F:\VS Backup" /MIR /NP /XF *.ISO /R:2 /W:5


REM Dummy command to clear the robocopy errorlevel

verify >nul

Backup Version and Space Management in Windows Server Backup

from http://blogs.technet.com/filecab/archive/2009/06/22/backup-version-and-space-management-in-windows-server-backup.aspx we find that:

- Delete system state backup and keep 10 most recent versions:
wbadmin delete systemstatebackup –keepversions:10

- List shadow copies for a volume:
vssadmin list shadows /for=\\?\Volume{8f1290ae-196f-11de-83ca-0015175a6279}

- Delete an old shadow copy using diskshadow command:
diskshadow
list shadows all
delete shadows oldest \\?\Volume{8f1290ae-196f-11de-83ca-0015175a6279}
delete shadows id {6316342e-e883-425b-b7f5-e80b13673625}

- Delete and restore windows backup catalog:
wbadmin get versions
wbadmin delete catalog
wbadmin restore catalog -backupTarget:\\?\Volume{8f1290ae-196f-11de83ca-0015175a6279}
wbadmin get versions -backupTarget:\\?\Volume{8f1290ae-196f-11de-83ca-0015175a6279}

Monday, August 10, 2009

Description of security events in Windows Vista and in Windows Server 2008

read this Microsoft article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;947226

Logon Type Codes

from http://www.windowsecurity.com/articles/Logon-Types.html we read:

Event IDs 528 and 540 signify a successful logon, event ID 538 a logoff and all the other events in this category identify different reasons for a logon failure. However, just knowing about a successful or failed logon attempt doesn’t fill in the whole picture. Because of all the services Windows offers, there are many different ways you can logon to a computer such as interactively at the computer’s local keyboard and screen, over the network through a drive mapping or through terminal services (aka remote desktop) or through IIS. Thankfully, logon/logoff events specify the Logon Type code which reveals the type of logon that prompted the event.

Logon Type 2 – Interactive
--------------------------
This is what occurs to you first when you think of logons, that is, a logon at the console of a computer. You’ll see type 2 logons when a user attempts to log on at the local keyboard and screen whether with a domain account or a local account from the computer’s local SAM. To tell the difference between an attempt to logon with a local or domain account look for the domain or computer name preceding the user name in the event’s description. Don’t forget that logon’s through an KVM over IP component or a server’s proprietary “lights-out” remote KVM feature are still interactive logons from the standpoint of Windows and will be logged as such.

Logon Type 3 – Network
----------------------
Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well such as most logons to IIS. (The exception is basic authentication which is explained in Logon Type 8 below.)

Logon Type 4 – Batch
--------------------
When Windows executes a scheduled task, the Scheduled Task service first creates a new logon session for the task so that it can run under the authority of the user account specified when the task was created. When this logon attempt occurs, Windows logs it as logon type 4. Other job scheduling systems, depending on their design, may also generate logon events with logon type 4 when starting jobs. Logon type 4 events are usually just innocent scheduled tasks startups but a malicious user could try to subvert security by trying to guess the password of an account through scheduled tasks. Such attempts would generate a logon failure event where logon type is 4. But logon failures associated with scheduled tasks can also result from an administrator entering the wrong password for the account at the time of task creation or from the password of an account being changed without modifying the scheduled task to use the new password.

Logon Type 5 – Service
----------------------
Similar to Scheduled Tasks, each service is configured to run as a specified user account. When a service starts, Windows first creates a logon session for the specified user account which results in a Logon/Logoff event with logon type 5. Failed logon events with logon type 5 usually indicate the password of an account has been changed without updating the service but there’s always the possibility of malicious users at work too. However this is less likely because creating a new service or editing an existing service by default requires membership in Administrators or Server Operators and such a user, if malicious, will likely already have enough authority to perpetrate his desired goal.

Logon Type 7 – Unlock
---------------------
Hopefully the workstations on your network automatically start a password protected screen saver when a user leaves their computer so that unattended workstations are protected from malicious use. When a user returns to their workstation and unlocks the console, Windows treats this as a logon and logs the appropriate Logon/Logoff event but in this case the logon type will be 7 – identifying the event as a workstation unlock attempt. Failed logons with logon type 7 indicate either a user entering the wrong password or a malicious user trying to unlock the computer by guessing the password.

Logon Type 8 – NetworkCleartext
-------------------------------
This logon type indicates a network logon like logon type 3 but where the password was sent over the network in the clear text. Windows server doesn’t allow connection to shared file or printers with clear text authentication. The only situation I’m aware of are logons from within an ASP script using the ADVAPI or when a user logs on to IIS using IIS’s basic authentication mode. In both cases the logon process in the event’s description will list advapi. Basic authentication is only dangerous if it isn’t wrapped inside an SSL session (i.e. https). As far as logons generated by an ASP, script remember that embedding passwords in source code is a bad practice for maintenance purposes as well as the risk that someone malicious will view the source code and thereby gain the password.

Logon Type 9 – NewCredentials
-----------------------------
If you use the RunAs command to start a program under a different user account and specify the /netonly switch, Windows records a logon/logoff event with logon type 9. When you start a program with RunAs using /netonly, the program executes on your local computer as the user you are currently logged on as but for any connections to other computers on the network, Windows connects you to those computers using the account specified on the RunAs command. Without /netonly Windows runs the program on the local computer and on the network as the specified user and records the logon event with logon type 2.

Logon Type 10 – RemoteInteractive
---------------------------------
When you access a computer through Terminal Services, Remote Desktop or Remote Assistance windows logs the logon attempt with logon type 10 which makes it easy to distinguish true console logons from a remote desktop session. Note however that prior to XP, Windows 2000 doesn’t use logon type 10 and terminal services logons are reported as logon type 2.

Logon Type 11 – CachedInteractive
---------------------------------
Windows supports a feature called Cached Logons which facilitate mobile users. When you are not connected to the your organization’s network and attempt to logon to your laptop with a domain account there’s no domain controller available to the laptop with which to verify your identity. To solve this problem, Windows caches a hash of the credentials of the last 10 interactive domain logons. Later when no domain controller is available, Windows uses these hashes to verify your identity when you attempt to logon with a domain account.