What’s New – Windows 8?

·         No Start Button – Metro UI

·         Simpler Task Manager

·         Improvements to Copy, Move, Rename and Delete

·         The New Windows Explorer

·         Fast Start up Mode

·         Re engineered Boot Experience in GUI mode

·         Sign in using Windows Live ID

·         Refresh/Reset Your PC

·         Scaling for Different Screen Sizes

·         Fast search starts by typing

·         Snap apps ........two apps can be used simultaneously

·         Picture password

·         Windows store like Apple store

·         Secure boot & Trusted boot

·         Win RT for ARM processors

·         Sky Drive

·         Multi-monitor options

·         Built-in Antivirus

·         The Facebook Experience...Amazing

·         Close apps automatically (App Killer)

·         Mount ISO without a problem

·         Hyper-V

·         IE 10

·         Profile base Apps

How to Install and Connect the Office 365 PowerShell cmdlets - Step01

You can install the cmdlets on a Windows 7 and Windows 8 or Windows Server 2008 R2 computer. You must have Windows PowerShell and the .NET Framework 3.5.1 enabled. You must install the Microsoft Online Services Sign-in Assistant. Download and install one of the following from the Microsoft Download Center:
Install the Microsoft Online Services Sign-in Assistant:
Microsoft Online Services Sign-In Assistant (IDCRL7) – 32 bit ,
Microsoft Online Services Sign-In Assistant (IDCRL7) – 64 bit
To install the Microsoft Online Services Module for Windows PowerShell:
Microsoft Online Services Module for Windows PowerShell (32-bit , 
Microsoft Online Services Module for Windows PowerShell (64-bit

For more information: Use Windows PowerShell to manage Office 365
Download and Install the Microsoft Online Services Module for Windows PowerShell for Single Sign on

Download the Microsoft Online Services Module

How to connect O365 PowerShell
Click Start , All Programs , Microsoft Online Services (Folder) and select Microsoft Online Services Module for Windows PowerShell

Method 1: Copy and paste the commands below:
 $LiveCred = Get-Credential
Connect-MSOLservice –Credential $livecred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Method 2:
Import-Module MSOnline
$Creds = Get-Credential
Connect-MsolService –Credential $Creds

SQL Server 2012-High-Availability Solutions

SQL Server provides several options for creating high availability for a server or database. The high-availability options include the following:

AlwaysOn Failover Cluster Instances (support version Enterprise, BI & Standard)

As part of the SQL Server AlwaysOn offering, AlwaysOn Failover Cluster Instances leverages Windows Server Failover Clustering (WSFC) functionality to provide local high availability through redundancy at the server-instance level—a failover cluster instance (FCI). An FCI is a single instance of SQL Server that is installed across Windows Server Failover Clustering (WSFC) nodes and, possibly, across multiple subnets. On the network, an FCI appears to be an instance of SQL Server running on a single computer, but the FCI provides failover from one WSFC node to another if the current node becomes unavailable.

For more information, see AlwaysOn Failover Cluster Instances (SQL Server).

AlwaysOn Availability Groups (Only Enterprise)

AlwaysOn Availability Groups is an enterprise-level high-availability and disaster recovery solution introduced in SQL Server 2012 to enable you to maximize availability for one or more user databases. AlwaysOn Availability Groups requires that the SQL Server instances reside on Windows Server Failover Clustering (WSFC) nodes.

For more information, see AlwaysOn Availability Groups (SQL Server).

Database mirroring (support version Enterprise, BI & Standard)

Database mirroring is a solution to increase database availability by supporting almost instantaneous failover. Database mirroring can be used to maintain a single standby database, or mirror database, for a corresponding production database that is referred to as the principal database.

For more information, see Database Mirroring (SQL Server).

Log shipping (support version Enterprise, BI & Standard)

Like AlwaysOn Availability Groups and database mirroring, log shipping operates at the database level. You can use log shipping to maintain one or more warm standby databases (referred to as secondary databases) for a single production database that is referred to as the primary database.

For more information about log shipping, see About Log Shipping (SQL Server).

Microsoft recommendation for providing data protection for your SQL Server environment are as follows:

• For data protection through a third-party shared disk solution (a SAN), we recommend that you use AlwaysOn Failover Cluster Instances.
• For data protection through SQL Server, we recommend that you use AlwaysOn Availability Groups. 

Tunnelling AD Traffic Using IPSec

If you don't like having to open this many ports, you could use IPSec to tunnel the traffic across the firewall. You could use ESP with encryption disabled, so the packets would still be cryptographically  signed and tunneled, but your intrusion detection systems (IDS) would still have visibility into the traffic.

Jason Fossen, who teaches the Securing Windows class at SANS, shared with us additional insights regarding the use of IPSec:

Because IPSec connections can be limited to those users and computers in specified global groups, is tightly integrated into the host-based Windows Firewall (which would be configured on all DMZ servers and participating controllers), and can optionally be tied into a Network Access Protection (NAP) infrastructure, the use of IPSec can provide benefits the perhaps outweigh the IDS/IPS hassles.

The Use of AD in the DMZ or a Screened Subnet

Jason Fossen also shared his thoughts on architecting AD in environments where some Windows servers reside close to the network's perimeter, such as in the DMZ or a screened subnet. He recommending implementing a  separate forest for DMZ servers that need to be domain members (perhaps with a one-way cross-forest trust to the internal forest), rather than joining DMZ servers to the internal forest directly. Jason continued:

The DMZ controller(s) will be located in a new perimeter network attached to a firewalling device.  When implementing a cross-forest trust, after configuring groups and permissions on the DMZ servers (which requires LDAP traffic), the only traffic that must be allowed through the firewall is Kerberos.  If the DMZ servers must be joined to the internal forest, then it’s better to place Read-Only Domain Controllers (RODC) in another perimeter network of the firewall for the sake of the DMZ servers.

Also, with the use of PKI, RADIUS, reverse proxy servers, etc., it has become less necessary to either join DMZ servers to the internal forest or to establish a one-way cross-forest trust from the DMZ forest to the internal one, even when users must authenticate with the internal forest credentials.