I have been using Windows Server 2012 for quite some time & 1 of the best features in Management & Automation using PowerShell Web Access.

So What is PowerShell Web Access??

Windows PowerShell® Web Access is a new feature in Windows Server® 2012 that acts as a Windows PowerShell gateway, providing a web-based Windows PowerShell console that is targeted at a remote computer. It enables IT Pros to run Windows PowerShell commands and scripts from a Windows PowerShell console in a web browser, with no Windows PowerShell, remote management software, or browser plug-in installation necessary on the client device. All that is required to run the web-based Windows PowerShell console is a properly-configured Windows PowerShell Web Access gateway, and a client device browser that supports JavaScript® and accepts cookies.

Examples of client devices include laptops, non-work personal computers, borrowed computers, tablet computers, web kiosks, computers that are not running a Windows-based operating system, and cell phone browsers. IT Pros can perform critical management tasks on remote Windows-based servers from devices that have access to an Internet connection and a web browser.

After successful gateway setup and configuration, users can access a Windows PowerShell console by using a web browser. When users open the secured Windows PowerShell Web Access website, they can run a web-based Windows PowerShell console after successful authentication.

Windows PowerShell Web Access setup and configuration is a three-step process:

1. Step 1: Installing Windows PowerShell Web Access
2. Step 2: Configuring the gateway
3. Step 3: Configuring authorization rules and site security

You can refer Microsoft TechNet Library to get detailed step by step article http://technet.microsoft.com/en-us/library/hh831611.aspx

In today’s blog post I will show you how can you deploy PowerShell Web Access in test environment. I will be using both GUI method i.e. Server Manager & PowerShell based scripts. So let’s get started.

My Test Environment.

I am using 2 virtual machines. Windows Server 2012 Domain Controller & Windows 8 Client machine.

DPE-WS12-VM01 - Windows Server 2012 Datacenter – Domain Controller, PowerShell Web Access Gateway & Destination.
DPE-WIN8-CLI01 - Windows 8 Enterprise – Domain joined client/workstation

Note: This is a test environment using Virtual Machines & leveraging sample self-signed test certificate.

Ideally, this is how the overall architecture would look like in production environment.

Step 1: Login to the Domain Controller machine DPE-WS12-VM01 to install PowerShell Web Access using Server Manager. WE WILL PERFORM THE STEPS USING SERVER MANAGER. Note: You can perform this Step 1 using PowerShell as well. Refer http://technet.microsoft.com/en-us/library/hh831611.aspx

• Open Server Manager & click on Add roles & features

• Click Next on wizard. On the next screen select Role-based or feature-based installation & click Next.

• Select the server in the list & click Next.

• Click Next on the Server Roles page. On the Features page scroll down, expand Windows PowerShell & select Windows PowerShell Web Access. Upon clicking a new pop-up will appear; click on Add Features. Lastly click Next.

• Click Next on Web Server Role (IIS) screen & also click Next on Role Services screen.

• Lastly click on Install.

• Once completed you will see the following screen. Click on Close to complete.

In Step 1, we have installed the features Windows PowerShell Web Access & server role Web Server Role (IIS).

Step 2: Now that we have installed the feature Windows PowerShell Web Access, we will now need to configure PowerShell Web Access Gateway so that my Application Pool should be available in my IIS Manager under Default Website. WE WILL PERFORM THE FOLLOWING USING POWERSHELL.

When you install the feature Windows PowerShell Web Access, the Application Folder is located in C:\Windows\Web\PowerShellWebAccess\wwwroot

Configure PowerShell Web Access Gateway using the following PowerShell Cmdlet.

• Do one of the following to open a Windows PowerShell session.

  • On the Windows desktop, right-click Windows PowerShell on the taskbar.
  • On the Windows Start screen, click Windows PowerShell.

• Type the following, and then press Enter.

  Install-PswaWebApplication –UseTestCertificate

The following settings are configured by running the cmdlet. You can change these manually in the IIS Manager console, if desired.

• Path: /pswa
• ApplicationPool: pswa_pool
• EnabledProtocols: http
• PhysicalPath: %windir%/Web/PowerShellWebAccess/wwwroot

At this stage you can see the PowerShell Web Access Application Pool configured in IIS Manager & also verify the same using the Web Browser. IMP Note: You cannot sign in until users have been granted access to the website by adding authorization rules.

Step 2A: To verify the same in IIS Manager, open Server Manager –> IIS –> Right click on DPE-WS12-VM01 & click on Internet Information Services (IIS) Manager

Step 2B: You can also verify the same from Web Browser. Go to CLIENT machine i.e. DPE-WIN8-CLI01. Open Internet Explorer & open https://DPE-WS12-VM01/pswa As we are using Test Certificate you will see the warning. Click on Continue.

Note: In production environment you must configure security using valid SSL certificate signed from the certificate provider.

Step 2C: Once you click on Continue you will the following Windows PowerShell Web Access login page.

Note: For more information about supported browsers and devices, see Browser and client device support in this document.

Step 3: Configure Authorization Rule & Site Security. WE WILL PERFORM THE FOLLOWING USING POWERSHELL

Now, we need to allow certain users access to the Windows PowerShell Web Access.

Every Windows PowerShell session uses a session configuration; if one is not specified for a session, Windows PowerShell uses the default, built-in Windows PowerShell session configuration, called Microsoft.PowerShell. The default session configuration includes all cmdlets that are available on a computer. Administrators can restrict access to all computers by defining a session configuration with a restricted runspace (a limited range of cmdlets and tasks that their end users could perform). A user who is granted access to one computer with either full language access or only the Windows PowerShell remote management cmdlets can connect to other computers that are connected to the first computer. Defining a restricted runspace can prevent users from accessing other computers from their allowed Windows PowerShell runspace, and improves the security of your Windows PowerShell Web Access environment. The session configuration can be distributed (by using Group Policy) to all computers that administrators want to make accessible through Windows PowerShell Web Access. For more information about session configurations, see about_Session_Configurations. The following are some examples of this scenario.

In this example, An administrator has set up a private test environment, and wants to allow all authorized network users access to all computers on the network to which they typically have access, with access to all session configurations to which they typically have access. Because this is a private test environment, the administrator creates an authorization rule that is not secure. The administrator runs the cmdlet Add-PswaAuthorizationRule * * *, which uses the wildcard character * to represent all users, all computers, and all configurations.

This rule is the equivalent of the following: Add-PswaAuthorizationRule –UserName * -ComputerName * -ConfigurationName *

We will perform the above step in PowerShell on Domain Controller DPE-WS12-VM01

With the above PowerShell we have allowed all authorized network users access to all computers on the network with access to all session configuration to which they typically have access.

Let’s Try Now…

Step 3A: Go to CLIENT MACHINE DPE-WIN8-CLI01. Open Internet Explorer & open https://DPE-WS12-VM01/pswa & click on Continue (as specified we are using Test Certificate)

You can also check optional connection settings…

Step 3B: On the login screen enter your administrator credentials & specify destination computer. Click on Sign In.

Step 3C: You will see the following status Signing In…

Upon successful login you will PowerShell Window in the Web Browser.

You can start running cmdlets in the above box.

I hope you enjoyed this post. I am looking forward to hear from you. Enjoy.

"Microsoft account" is the new name for what used to be called a "Windows Live ID." Your Microsoft account is the combination of an email address and a password that you use to sign in to services like Hotmail, SkyDrive, Windows Phone, or Xbox LIVE. If you use an email address and password to sign in to these or other services, you already have a Microsoft account—but you can also sign up for a new one at any time.

Over time, all Microsoft services will be switching from the old name to the new one. You might continue to see mentions of "Windows Live ID" instead of "Microsoft account" for a while—for example, on xbox.com or windowsphone.com—but the names mean the same thing, and the services will be updated soon.

http://windows.microsoft.com/en-US/windows-live/sign-in-what-is-microsoft-account

First I would like to take this opportunity to say THANK YOU very much to all the IT Professionals across the globe I worked with directly or indirectly for your continuous support. For Microsoft July marks a new year starting today.

I will be connecting with you all in a same way in this year too with lot of new content. This is the year of WINDOWS with the products like Windows 8, Windows Server 2012, Windows Azure & Windows Phone 8 coming up soon. I am looking forward to have another exciting & rocking year.

If you have any queries/feedback, as always you can write back to me on aviraj@microsoft.com

Regards,
Aviraj Ajgekar
Technical Evangelist

Just got to read this fantastic article..

For details visit http://windowsteamblog.com/windows/b/bloggingwindows/archive/2012/07/02/upgrade-to-windows-8-pro-for-39-99.aspx

Have a great day ahead.

Microsoft DirectAccess Connectivity Assistant (DCA) 2.0 RC can be used by computers running Windows 7 when connecting to internal corporate networks with DirectAccess in Windows Server 2012 RC. It improves the DirectAccess connection experience, supports one-time password (OTP) authentication for DirectAccess users and helps organizations reduce the cost of supporting DirectAccess users.

Overview

DCA 2.0 RC provides the following functionality:
• Provides DirectAccess users with connectivity information. Users can view their DirectAccess connectivity status at all times.
• Provides diagnostics and troubleshooting features. DCA 2.0 RC provides tools to help users reconnect if problems arise, and create diagnostics to provide IT administrators with troubleshooting information.
• Supports one-time password (OTP) authentication for DirectAccess users required to authenticate using OTP.
Note: DCA 2.0 RC can be installed on Windows 7 computers that connect to the corporate network using DirectAccess running on a Windows Server 2012 RC computer. It can be installed on Windows 7 computers that do not have DCA installed, or on computers running DCA 1.0 or DCA 1.5. DCA 2.0 RC should not be installed on computers running Windows 8 Consumer Preview. It should also not be installed on Windows 7 computers that connect to the corporate network using DirectAccess running on a Windows Server 2008 R2 computer or on a Forefront UAG server.
The download includes the following components:
• A zip file (DirectAccess_Connectivity_Assistant_2_0_RC.zip) containing a collection of all the files in this download.
• GPO templates (DirectAccess_Connectivity_Assistant_2_0_RC_GP.adml; DirectAccess_Connectivity_Assistant_2_0_RC_GP.admx) for configuring DCA settings on client computers.
• Installation files (DirectAccess_Connectivity_Assistant_2_0_RC_x64.msi; DirectAccess_Connectivity_Assistant_2_0_RC_x86.msi) required to install the application on 64-bit or 32-bit client computers.
• An administrators guide (DirectAccess_Connectivity_Assistant_2_0_RC_AdminGuide.docx) that describes how to configure the GPO templates, and install the application.
• A zip file (DirectAccess_Connectivity_Assistant_2_0_RC_UserGuide.zip) containing an end-user help file that can be distributed to client computers running DirectAccess Connectivity Assistant (DCA) 2.0. The zip file contains the document in all languages supported by DCA 2.0 RC.
Note that when you install DCA 2.0, the .msi file runs in English. After Setup, the DCA user interface appears on the end-user computer in the language specified by the operating system.

DOWNLOAD HERE