Source: Microsoft MSDN

ReFS, has been designed from the ground up to meet a broad set of customer requirements, both today’s and tomorrow’s, for all the different ways that Windows is deployed.

The key goals of ReFS are:

• Maintain a high degree of compatibility with a subset of NTFS features that are widely adopted while deprecating others that provide limited value at the cost of system complexity and footprint.
• Verify and auto-correct data. Data can get corrupted due to a number of reasons and therefore must be verified and, when possible, corrected automatically. Metadata must not be written in place to avoid the possibility of “torn writes,” which we will talk about in more detail below.
• Optimize for extreme scale. Use scalable structures for everything. Don’t assume that disk-checking algorithms, in particular, can scale to the size of the entire file system.
• Never take the file system offline. Assume that in the event of corruptions, it is advantageous to isolate the fault while allowing access to the rest of the volume. This is done while salvaging the maximum amount of data possible, all done live.
• Provide a full end-to-end resiliency architecture when used in conjunction with the Storage Spaces feature, which was co-designed and built in conjunction with ReFS.

The key features of ReFS are as follows (note that some of these features are provided in conjunction with Storage Spaces).

• Metadata integrity with checksums
• Integrity streams providing optional user data integrity
• Allocate on write transactional model for robust disk updates (also known as copy on write)
• Large volume, file and directory sizes
• Storage pooling and virtualization makes file system creation and management easy
• Data striping for performance (bandwidth can be managed) and redundancy for fault tolerance
• Disk scrubbing for protection against latent disk errors
• Resiliency to corruptions with "salvage" for maximum volume availability in all cases
• Shared storage pools across machines for additional failure tolerance and load balancing

In addition, ReFS inherits the features and semantics from NTFS including BitLocker encryption, access-control lists for security, USN journal, change notifications, symbolic links, junction points, mount points, reparse points, volume snapshots, file IDs, and oplocks.

And of course, data stored on ReFS is accessible through the same file access APIs on clients that are used on any operating system that can access today’s NTFS volumes.

Key design attributes and features

Our design attributes are closely related to our goals. As we go through these attributes, keep in mind the history of producing file systems used by hundreds of millions of devices scaling from the smallest footprint machines to the largest data centers, from the smallest storage format to the largest multi-spindle format, from solid state storage to the largest drives and storage systems available. Yet at the same time, Windows file systems are accessed by the widest array of application and system software anywhere. ReFS takes that learning and builds on it. We didn’t start from scratch, but reimagined it where it made sense and built on the right parts of NTFS where that made sense. Above all, we are delivering this in a pragmatic manner consistent with the delivery of a major file system—something only Microsoft has done at this scale.

Code reuse and compatibility

When we look at the file system API, this is the area where compatibility is the most critical and technically, the most challenging. Rewriting the code that implements file system semantics would not lead to the right level of compatibility and the issues introduced would be highly dependent on application code, call timing, and hardware. Therefore in building ReFS, we reused the code responsible for implementing the Windows file system semantics. This code implements the file system interface (read, write, open, close, change notification, etc.), maintains in-memory file and volume state, enforces security, and maintains memory caching and synchronization for file data. This reuse ensures a high degree of compatibility with the features of NTFS that we’re carrying forward.

Underneath this reused portion, the NTFS version of the code-base uses a newly architected engine that implements on-disk structures such as the Master File Table (MFT) to represent files and directories. ReFS combines this reused code with a brand-new engine, where a significant portion of the innovation behind ReFS lies. Graphically, it looks like this:

Read more at the source: Microsoft MSDN

During migration projects a lot of customers asks me how to import all accepted domains the easy way. The script I provide below is very basic but it will save you a lot of time.

But first create a CSV file with on the first line AcceptedDomains. Insert all your accepted domains on seperate lines starting from the second line.

$File = Read-Host "Please enter location and filename of the CSV file (example: D:\Temp\AcceptedDomain.CSV)"

# Reading of all lines within the specified CSV file.

$list = Import-Csv $File

foreach($entry in $list) {

# Reading the AcceptedDomain variable from the CSV file.

$AcceptedDomain = $entry.AcceptedDomain

# Running the powershell command for creation of all Accepted Domains.

New-AcceptedDomain -Name $AcceptedDomain -DomainName $AcceptedDomain

}

This is the third part (Part 1, Part 2) of the how-to guide on installing and configuring an offline Root Certificate Authority on a Windows Server 2008 R2 core edtion.

Within this part we are going to install and configure Active Directory Certificate Services (ADCS) on the Root CA. Also we are going to backup the root certificate with private key to external storage and encrypt this drive Bitlocker to go.

Prerequisites

The following must be available before using this guide:

• Part 1 and Part 2 of the installation guide must be completed;
• Root access to the Root CA server (ILO, VMware, vSphere console);
• SetupCA.vbs must be downloaded (click here) and stored on the Root CA (C:\Temp)
• One or two USB drives (dedicated for the backup of the root certificate and private key).

Installation steps

1. Open the Root CA and run the following command to install Certificate Services: start /w ocsetup.exe CertificateServices /norestart /quiet

2. Check if the installation succeeded by running the following command: Dism /online /get-features /Format:Table

3. Configure Active Directory Certificate Services by running the following command: Cscript /nologo C:\Temp\SetupCA.vbs /is /sn <RootCA netbios name>  /sk 4096 /sp "RSA#Microsoft Software Key Storage Provider" /sa SHA256

Note: Change <RootCA netbios name> to the netbios name of your Root CA server (in my case RootCA).

4. After the completion of step 3 type the following command to check if the configuration succeeded: type _SetupCA.log

5. Now we are going to stop the Certificate Services service by running the following command: net stop CertSvc

6. Now we are going to change the the validity period of the root certificate to 10 years by running the following command: Reg Add HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\RootCA /V ValidityPeriodUnits /t REG_DWORD /d 10 /f

Note: Change Configuration\RootCA to Configuration\NetbiosNameOfYourServer

7. Now start the Certificate Services service by running the following command: net start CertSvc

8. Now insert an formatted USB drive to the computer (if using VMware please allow USB drives to connect directly to the Root CA).

9. Now run the following command to backup the certificate: certutil –backupKey <drive letter of the USB drive>

10. You will need to provide a password for the P12 backup file. The password most be stored at a save location and managed by an security officer.

11. Now we are going to encrypt the drive with Bitlocker to go by running the following command: Manage-bde -on <drive letter of the USB drive> -pw <very complex password>

12. When all intermediate or issuing CAs are deployed this server must be shutdown.

• Virtual server: Save the virtual harddrive of the VM to two USB drives (one for backup) and delete the server from the physical host. The USB drives must be stored in seperate secured locations (vault).
• Physical server: Store the harddrives in seperate secured locations (vault).

In total we have the following security measures:

• Password of the administrator account is complex.
• Drive of the Root CA is encrypted with Bitlocker.
• Startup disk of the Root CA is stored in a secure location and managed by an security officer.
• Backup of the private key of the root certificate is stored on a encrypted password protected USB disk and managed by an security officer.
• The Root CA is shutdown and all disks are stored in seperated secured locations.

To provide an extra level of security (and redundancy) divide all passwords and physical drives to two security officers. When the Root CA must be started two security officers are needed to start the server.

This is the second part (Part 1) of the how-to guide on installing and configuring an offline Root Certificate Authority on a Windows Server 2008 R2 core edtion.

Within this part we are going to encrypt the OS drive with BitLocker. By encrypting the drive it will be almost impossible to steal the private key of the root certificate. Within this guide we are going to use a virtual machine on VMware (Hyper-V or XenServer are also supported). Because our virtual machine does not have a TPM (Trusted Platform Module) we are using a virtual floppy which will be needed everytime the server will be powered on.

This guide can also be used on all Windows Server 2008 R2 core servers. 

Prerequisites

The following must be available before using this guide:

• Root access to the server (ILO, VMware, vSphere console);
• Windows Server 2008 R2 core edition already installed;
• A server with Windows Server 2008 R2 full and the Bitlocker feature installed.

Installation steps

Part 2: Encrypting the drive with Bitlocker

1. Install the Bitlocker feature by running the following command: Dism /online /enable-feature /featurename:BitLocker

2. Press "Y" to restart the server.

3. When restarted logon to the RootCA and run the following command: netsh advfirewall set rule group="Remote Service Management" new enable=yes

4. Now logon to a Windows Server 2008 full version and copy three files (bdehdcfg.exe,bdehdcfglib.dll and reagent.dll ) from the %WinDir%\System32 directory to the same directory on the Root CA.

5. On the same full edition server run the following command: cmdkey /add:<Hostname of Root CA>  /User:<Computername\Administrator> /pass:<password>

(in my case it was: cmdkey /add:RootCA /User:RootCA\Administrator /pass:myComplexPassw0rd)

6. Now run the following command on the same server: mmc

7. Click on File -> Add/Remove snap-in -> Group Policy Object editor -> Add -> Browse -> Another Computer -> Hostname of the server (RootCA) -> OK -> Finish

8. Navigate to Computer Configuration\Policies\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives\Require Additional Authentication At Startup

9. Select Enable and make sure that Allow Bitlocker without a compatible TPM is enabled.

10. You can now log out on the Win2K8 R2 full server.

11. Logon to the RootCA server and run the following command: GPupdate (to make sure that the settings are applied)

12. Run the following command on the Root CA to create the Bitlocker partition S: bdehdcfg -target c: shrink -newdriveletter s: -size 300

13. Now insert an formatted (FAT32) USB (physical machine) or an virtual floppy disk (virtual machine) to the server.

14. To enable bitlocker on the OS partition run the following command: Manage-BDE -on C: -StartupKey A: (A: was the location of my virtual floppy disk)

15. Now restart the server (with the virtual floppy or usb) by running the following command: shutdown -r -t 0

Note: Make sure to boot from you harddrive.

 16. When the server is restarted logon to the computer and run the following command to check the status of BitLocker: Manage-BDE -status

17. Now wait for about half an hour (depends on your disk size) and check the status again with the same command as step 16.

18. To check if the server can be restarted without the BitLock startup key please reboot the server without the virtual floppy or usb disk mounted.

End of Part 2. Next part: Configuring Certificate Services on the Root CA.

This guide explains how to install and configure an offline Root Certificate Authority on a Windows Server 2008 R2 core edtion.

This guide is splitted in three seperate parts:

• Part 1: Introduction and pre-installation tasks
• Part 2: Encrypting the drive of the Root CA using BitLocker
• Part 3: Installing Active Directory Certificate Services on the Root CA

Main reason to configure the Root CA on a core edition is to lower the attack surface. The attack surface should be as low as possible to prevent hackers from stealing the private key of the root certificate. Therefore most of the time the Root CA will be shutdown and disconnected from the network. More about security hardening on an Root CA in a later article.

Prerequisites

The following must be available before using this guide:

• A dedicated physical or virtual machine;
• Root access to the server (ILO, VMware, vSphere console);
• Windows Server 2008 R2 core edition already installed;
• Hostname and network settings already configured;
• Very complex password set for the administrator account;
• Firewall must be on with no exceptions;
• Access to Windows update, WSUS, SCCM or other patching mechanism.

Installation steps

Step1: Install all updates (securing the server)

1. Open up the command prompt on the Root CA server.

2. Run the following command to open up the server configuration: sconfig

3. Press "6" to download and install Windows Updates.

4. Press "A" to search for all available updates.

5. Press "A" to select all updates.

6. Click Yes to restart te server.

This is the end of part 1. Next part we are going to encrypt the drive of the Root CA with BitLocker.

Source: Microsoft

Microsoft Exchange Server 2010 SP2 helps IT Professionals achieve new levels of reliability with greater flexibility, enhanced user experiences, and increased protection for business communications.

• Flexible and reliable – Exchange Server 2010 SP2 gives you the flexibility to tailor your deployment based on your company's unique needs and a simplified way to keep e-mail continuously available for your users.
• Anywhere access – Exchange Server 2010 SP2 helps your users get more done by giving them the freedom to securely access all their communications – e-mail, voice mail, instant messaging, and more – from virtually any platform, Web browser, or device.
• Protection and compliance – Exchange Server 2010 SP2 delivers integrated information loss prevention, and compliance tools aimed at helping you simplify the process of protecting your company's communications and meeting regulatory requirements.

You must accept the license terms for the software before you are authorized to use it. There is no product support for the trial edition of the software. You are welcome to participate in the forums to share your trial experiences with others and to ask for advice.

Download it here.

I have created an script which will remotely enables a users mailbox.

# This powershell script creates a remote mailbox.
# Created by Bart Timmermans
$Server = Read-Host "(Please enter the hostname of your Exchange 2010 Server)"
$User = Read-Host "Please enter the username (domain\user)"
$ServerFull = "HTTP://" + $Server + "/Powershell"

# Start session to remote Exchange 2010 server.
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $ServerFull -Authentication Kerberos
Import-PSSession $Session

# Create new mailbox
Enable-Mailbox -identity $User

Source: Microsoft Exchange blog

Earlier today the Exchange CXP team released Update Rollup 4 for Exchange Server 2010 SP1 to the Download Center.

This update contains a number of customer-reported and internally found issues since the release of RU1. See 'KB 2509910: Description of Update Rollup 4 for Exchange Server 2010 Service Pack 1' for more details. In particular we would like to specifically call out the following fixes which are included in this release:

• 2519359 Unable to Create a 'Reply With' Rule on Public Folders Even With Owner and Send As Permissions
• 2394554 Generating DSN fails if original mail uses non-support encoding charset.
• 2490134 Outlook 2007 does not deliver "Delayed Delivery" Messages against an Exchange 2010 Server in Online mode with any additional Transport loaded in the Outlook Profile

Some of the above KnowledgeBase articles are not replicated/live at the time of writing this post. Please check back later in the day if you can't reach them.

Update Rollup 5 for Exchange Server 2010 Service Pack 1 is currently scheduled to release in August 2011.

General Notes

Note for Exchange 2010 Customers using the Arabic and Hebrew language version: We introduced two new languages with the release of Service Pack 1, Arabic and Hebrew. At present we are working through the process of modifying our installers to incorporate these two languages. Customers running either of the two language versions affected are advised to download and install the English language version of the rollup which contains all of the same fixes.

Download it here.

Source: Microsoft

The System Center Orchestrator Beta product provides the capability of automation of workflows (Runbooks) across other System Center and 3rd party products. These runbooks are created in the Runbook Designer, deployed via the Deployment Manager and run and monitored locally or remotely via the Orchestrator Console.

Feature Bullet Summary:
 

• Management Server
• Orchestrator Console
• Runbook Designer
• Deployment Manager
• Web service for reporting

Download the beta here.