With the recent releases of Exchange Server 2013 RTM CU1, Exchange 2013 sizing guidance, Exchange 2013 Server Role Requirements Calculator, and the updated Exchange 2013 Deployment Asistant, on-premises customers now have the tools you need to begin designing and performing migrations to Exchange Server 2013. Many of you have introduced Exchange 2013 RTM CU1 into your test environments alongside Exchange 2010 SP3 and/or Exchange 2007 SP3 RU10, and are readying yourselves for the production migrations.

There’s one particular Exchange 2010 design choice some customers made that could throw a monkey wrench into your upgrade plans to Exchange 2013, and we want to walk you through how to mitigate it so you can move forward. If you’re still in the design or deployment phase of Exchange Server 2010, we recommend you continue reading this article so you can make some intelligent design choices which will benefit you when you migrate to Exchange 2013 or later.

What is the situation we need to look for?

In Exchange 2010, all Outlook clients in the most typical configurations will utilize MAPI/RPC or Outlook Anywhere (RPC over HTTPS) connections to a Client Access Server. The MAPI/RPC clients connect to the CAS Array Object FQDN (also known as the RPC endpoint) for Mailbox access and the HTTPS based clients connect to the Outlook Anywhere hostname (also known as the RPC proxy endpoint) for all Mailbox and Public Folder access. In addition to these primary connections, other HTTPS based workloads such as EAS, ECP, OAB, and EWS may be sharing the same FQDN as Outlook Anywhere. In some environments you may also be sharing the same FQDN with POP/IMAP based clients and using it as an SMTP endpoint for internal mail submissions.

In Exchange 2010, the recommendation was to utilize split DNS and ensure that the CAS Array Object FQDN was only resolvable via DNS by internal clients. External clients should never be able to resolve the CAS Array Object FQDN. This was covered previously in item #4 of Demystifying the CAS Array Object – Part 2. If you put those two design rules together you come to the conclusion your ClientAccessArray FQDN used by the mailbox database RpcClientAccessServer property should have been an internal-only unique FQDN not utilized by any workload besides MAPI/RPC clients.

Take the following chart as an example of what a suggested configuration in a split DNS configuration would have looked like.

If your do not utilize split DNS, then a suggested configuration may have been.

In speaking with our Premier Field Engineers and MCS consultants, we learned that some of our customers did not choose to use a unique ClientAccessArray FQDN. This design choice may manifest itself in one of two ways. The MAPI/RPC and HTTPS workloads may both utilize the mail.contoso.com FQDN internally and externally, or a unique external FQDN of mail.contoso.com is used while internal MAPI/RPC and HTTPS workloads share mail-int.contoso.com. The shared FQDN in either situation is ambiguous because we can’t look at it and immediately understand the workload type that’s using it. Perhaps we were not clear enough in our original guidance, or customers felt fewer names would help reduce overall design complexity since everything appeared to work with this configuration.

Take a look at the figure below and the FQDNs in use for some of the different workloads. Shown are EWS, ECP, OWA, CAS Array Object, and Outlook Anywhere External Hostname. The yellow arrow specifically points out the CAS Array Object, the value used as the RpcClientAccessServer for Exchange 2010 mailbox databases, and seen in the Server field of an Outlook profile for an Exchange 2010 mailbox.

An Exchange 2010 deployment with a single ambiguous URL for all workloads.

Let us pause for a moment to visualize what we have talked about so far. If we were to compare an Exchange 2010 environment using ambiguous URLs to one not using ambiguous URLs, it would look like the following diagrams. Notice the first diagram below uses the same FQDN for Outlook MAPI/RPC based traffic and HTTPS based traffic.

If we were to then look at an environment not utilizing ambiguous URLs, we see the clients utilize unique FQDNs for MAPI/RPC based traffic and HTTPS based traffic. In addition, the FQDN utilized for MAPI/RPC based traffic is only resolvable via internal DNS.

If your environment does not look like the one above using ambiguous URLs, then you can go hit the coffee shop for a while or play some XBOX 360. Tell your boss we gave the okay. If your environment does look similar to the first example using ambiguous URLs or you are in the planning stages for Exchange 2010, then please read on as we need you to perform some extra steps when migrating to Exchange 2013.

So what’s the big deal? It is functional this way isn’t it?

While this may be working for you today, it certainly will not work tomorrow if you migrate to Exchange 2013. In this scenario where both the MAPI/RPC and HTTP workloads are using the same FQDN you cannot successfully move the FQDN to CAS 2013 without breaking your MAPI/RPC client connectivity entirely. I repeat, your MAPI/RPC clients will start failing to connect via MAPI/RPC once their DNS cache expires after the shared FQDN is moved to CAS 2013. The MAPI/RPC clients will fail to connect because CAS 2013 does not know how to handle direct MAPI/RPC connections as all Windows based Outlook clients utilize MAPI over a RPC over HTTPS connection in Exchange 2013. There is a chance your Outlook clients may successfully fall back to HTTPS only if Outlook Anywhere is currently enabled for Exchange 2010 when the failure to connect via MAPI/RPC takes place, but this article will help with the following.

1. Ensure you are in full control of what will take place
2. Ensure you are in full control of when #1 takes place
3. Ensure you are in a supported server + client configuration
4. Ensure environments with Outlook Anywhere disabled for Exchange 2010 know their path forward
5. Help remove the possibility of any clients not automatically falling back to HTTPS
6. Remove the potentially long delay when Outlook does fail to via MAPI/RPC even though it can resolve the MAPI/RPC URL and then falls back to HTTPS

Shoot… this looks like us. What should we do immediately?

First off, if you are still in the planning stages of Exchange 2010 you need to take our warning to heart and immediately change your design to use a specific internal-only FQDN for MAPI/RPC clients. If you are in the middle of a 2010 deployment using an Ambiguous URL I recommend you change your ClientAccessArray FQDN to a unique name and update the mailbox database RpcClientAccessServer values on all Exchange 2010 mailbox databases accordingly. Fixing this item mid-migration to Exchange 2010 or even in your fully migrated environment will ensure any newly created or manually repaired Outlook profiles are protected, but it will not automatically fix existing Outlook clients with the old value in the server field.

While not necessary as long as you go through our mitigation steps below, any existing Outlook profiles could be manually repaired to reflect the new value. If you are curious why a manual repair is necessary you can refer to items #5 and #6 in Demystifying the CAS Array Object – Part 2. Again, forcing this update is not necessary if you follow our mitigation steps later in this article. However, if you were to choose to update some specific Outlook profiles we suggest you perform those steps in your test environment first to make sure you have the process down correctly.

Additionally as we previously discussed in item #3 of Demystifying the CAS Array Object – Part 1, the ClientAccessArray FQDN is not needed in your SSL certificate as it is not being used for HTTPS based traffic. Because of this, the only thing you would need to do is create a new internal DNS record, update your ClientAccessArray FQDN, and finally update your Exchange 2010 Mailbox Database RpcClientAccessServer values. It bears repeating that you do not have to get a new SSL certificate only to fix an Ambiguous URL situation.

Ok, fixed that… now what about the clients we don’t want to repair manually?

Our suggestion is to implement Outlook Anywhere internally for all users prior to introducing Exchange Server 2013 to the environment.

Many of our customers have already moved to Outlook Anywhere internally for all Windows Outlook clients. In fact, those of you reading this with OA in use internally are good to proceed to the coffee shop or go play XBOX 360 with the other folks if you’d like to.

Now for the rest of you… sit a little closer. Go ahead and fill in, there are plenty of seats in the front row like usual.

In Exchange Server 2013 all Windows Outlook clients operate in Outlook Anywhere mode internally. By following these mitigation steps you will be one step ahead of where you will end up after your migration to Exchange Server 2013 anyways.

If you do not have Outlook Anywhere enabled at all in your environment, please see Enable Outlook Anywhere on TechNet for steps on how to enable it in Exchange 2010. If your company does not wish to provide external access for Outlook Anywhere that is ok. By simply enabling Outlook Anywhere you will not be providing remote access unless you also publish the /rpc virtual directory to the Internet.

It is suggested customers, especially very large ones, consider enabling Kerberos authentication to avoid any potential performance issues you may run into utilizing the default NTLM authentication. Information on how to configure Kerberos Authentication can be found here on TechNet for Exchange Server 2010 and the steps for Exchange Server 2013 are similar which we will have documentation for in the near future. However, please keep in mind Kerberos authentication with Outlook Anywhere is only supported with Windows Vista or later.

By default with Outlook Anywhere enabled in the environment your clients prefer RPC/TCP connections when on Fast Networks as seen below.

The trick we use to force Outlook Anywhere to also be used internally is via Autodiscover. Using Autodiscover we can make Windows Outlook clients prefer RPC/HTTPS on both Fast and Slow networks as seen here.

The method used to make clients always prefer HTTPS is configuring the OutlookProviderFlags option via the Set-OutlookProvider cmdlet. The following commands are executed from the Exchange 2010 Management Shell.

Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect

Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect

If for any reason you need to put the configuration back to its default settings, issue the following commands and clients will no longer prefer HTTP on Fast Networks.

Set-OutlookProvider EXPR -OutlookProviderFlags:None

Set-OutlookProvider EXCH -OutlookProviderFlags:None

You can prepare to introduce Exchange Server 2013 to your environment once all of your Windows Outlook clients are preferring HTTP on both fast and slow networks and are connecting through mail.contoso.com for RPC over HTTPS connections.

There are a small number of things we would like to call out as you plan this migration to enable Outlook Anywhere for all internal clients.

First, your front end infrastructure (CAS 2013, Load Balancer, etc…) must ready to immediately handle the full production load of Windows Outlook clients when you re-point the mail.contoso.com FQDN in DNS.

Second, if your Exchange 2010 Client Access Servers were not scaled for 100% Outlook Anywhere connections then performance should be monitored when OA is enabled and all clients are moved from MAPI/RPC based to HTTPS based workloads. You should be ready to scale out your CAS 2010 infrastructure if necessary to mitigate any possible performance issues.

Lastly, Windows Outlook clients older than Outlook 2007 are not supported going through CAS 2013 even if their mailbox is on an older Exchange version. All Windows Outlook clients going through CAS 2013 have to be at least the minimum versions supported by Exchange 2013. Any unsupported clients, such as Outlook 2003, do not support Autodiscover and would have to be manually with a new MAPI/RPC specific endpoint to assure they continue communicating with Exchange 2010 until the client can be updated and the mailbox migrated to Exchange 2013.

Note: The easiest way to confirm what major/minor version of Outlook you have is to look at the version of OUTLOOK.EXE and EMSMDB32.DLL via Windows Explorer or to run an inventory report through Microsoft System Center Configuration Manager or similar software. The minimum version numbers Exchange Server 2013 supports for on-premises deployments are provided below.

• Outlook 2007: 12.0.6665.5000 (SP3 + the November 2012 Public Update or any later PU)
• Outlook 2010: 14.0.6126.5000 (SP1 + the November 2012 Public Update or any later PU)
• Outlook 2013: 15.0.4420.1017 (RTM or later)

If we were to visualize the mitigation steps from start to end we need to compare it between phases.

First, the upper area of the below diagram depicts the start state of the environment with internal Windows Outlook clients utilizing MAPI/RPC and ambiguous URLs for their HTTPS based workloads. The lower area of the diagram depicts the same environment, but we have now forced Outlook Anywhere to be used by internal Windows Outlook clients. This change has forced all mailbox and public folder access traffic over HTTPS through the mail.contoso.com Outlook Anywhere FQDN.

We now have all Windows Outlook clients utilizing Outlook Anywhere internally by levering Autodiscover to force the preference of HTTPS. Now that all Windows Outlook traffic is routed through mail.contoso.com via HTTPS, the ambiguous URL problem has been mitigated. However, you may have other applications integrating with Exchange whom are unable to utilize Outlook Anywhere and/or Autodiscover. These applications will also be affected if you were to update the mail.contoso.com DNS entry to point at Exchange 2013. Before moving onto the second step it may be most efficient to add a HOSTS file entry on the servers hosting these external applications to force resolution of mail.contoso.com to the Layer-7 Load Balancer used by Exchange 2010. This should allow you to temporarily continue routing external application traffic that needs to talk to only Exchange 2010 via MAPI/RPC while you work on updating the applications to be Outlook Anywhere compatible, which they will need to be before they can ever connect to Exchange 2013.

Having dealt with both the Windows Outlook clients and third-party applications whom cannot utilize Outlook Anywhere, we can now move onto the second step. The second step is executed when you are ready to introduce Exchange 2013 to the environment.

The below diagram starts by showing where we finished after executing step one. The lower area of the below diagram shows that we have updated DNS to point the mail.contoso.com entry to the new IP of the new Exchange 2013 load balancer configuration. Because of the HOSTS entry we made our application server continues talking to the old Layer-7 load balancer for its MAPI over RPC/TCP connections. Exchange 2013 CAS will now receive all client traffic and then we proxy traffic for users still on Exchange 2010 back to the Exchange 2010 CAS infrastructure. The redundant CAS was removed from the diagram to simplify the view and simply show traffic flow.

In summary, we hope those of you in this unique configuration will be able to smoothly migrate from Exchange 2010 to Exchange 2013 now that you have these mitigation steps. Some of you may identify other potential methods to use and wonder why we are offering only a single mitigation approach. There were many methods investigated, but this mitigation approach came back every time as the most straightforward method to implement, maintain, and support. Given the potential complexity of this change we invite you to ask follow-up questions at the follow Exchange Server Forum where we can often better interact with you than the comments format allows.

Exchange Server Forum: Exchange Server 2013 – Setup, Deployment, Updates, and Migration

Brian Day
Senior Program Manager
Exchange Customer Experience

Exchange Team Blog

Hey all,

If you are interested in an “incrementally expandable” Virtual Desktop Infrastructure (VDI) pool architecture and want to hear about some benchmarking results we just completed, you are in the right place!

Recently we partnered with Dell to build a 2000-seat VDI deployment (all pooled virtual desktops) at our Enterprise Engineering Center (EEC) in Redmond, based on a reference architecture we had developed jointly that allows easy, incremental expansion of capacity with minimal impact on the shared storage or the storage network. The lab environment was fully isolated to minimize interference from the corporate network, and the networking back bone was built on 2×10 GB network infrastructures.

The key idea of this architecture is that VDI compute and storage are per host; think of these as VDI pods, and you can just add more pods to host more users. The key advantage of such a design is that we only need high availability (HA) type storage for user docs and settings, and typically such an infrastructure already exists in an enterprise. If not, it can be built mostly independent of the VDI. And just to complete the picture, some shared storage might be required depending on your preference for HA configuration of back-end services such as SQL, although the VDI-specific services have application-level HA and can work either way.

Following is a high level overview of our deployment.

In the preceding diagram, please note that the capacity of this deployment is primarily a function of the number of VDI hosts; one could easily add more hosts to grow capacity without upgrading the management infrastructure, but bear in mind that you may need to increase storage for user docs and settings (this analogy holds for traditional desktops with roaming or redirected folders too). That said, another benefit of this architecture is that the design of storage for user docs and settings is decoupled from the VDI design, which makes it especially ideal for pooled virtual desktops.

So with that quick intro, let’s jump into the details and results!

Results

We deployed a Win8-x86 virtual machine with Office 2013, and optimized the virtual machines for the VDI workload. Each virtual machine had a single vCPU, and was allocated about 800 MB of RAM to start with. We also enabled Hyper-V’s Dynamic Memory for better memory utilization (especially helpful for the VDI workload). The R720 hosts came with 256 GB of RAM.

We built a VSI benchmarking infrastructure (v 3.7) to run the VSI Medium workload (http://www.loginvsi.com/) on this deployment. All launchers were virtual machines on a pair of Dell 910 Hyper-V servers; we used about 100 launchers (20 connections per launcher).

Although we could have pushed each host to maximum CPU, we decided to keep them at 80% and run 150 virtual machines per host to test a closer to a real-world use case, allowing some headroom for unexpected surge. That said, I’d like do another blog just to describe a single host’s behavior when pushing CPU to max, but that’s a side note.

So following is the VSI benchmarking results for our 2000-seat pooled virtual desktop deployment, where the VSI maximum was not reached.

The logon interval was over a period of one hour, so 2000 logons in 60 minutes, where each virtual machine would start running the VSI medium workload within ~15 seconds after logon.

The load on the VDI management infrastructure was pretty low too, that’s why such a deployment can easily grow by adding more hosts, since the management infrastructure shows a very light load based on this 2000-seat run.

Network load

In the LAN environment that we had set up (2×10 GB), the RDP generated load on the network was about 400 kbps (average) per pooled virtual desktop running the VSI medium workload, so user traffic for this 2000-seat deployment would be about 800 Mbps. This is well below the capacity of the network infrastructure we had deployed.

SQL load

The following chart shows the CPU and IO load on the SQL virtual machine.

As some of you may know, SQL is a key part of our high availability (HA) RD Connection Broker model in Windows Server 2012, where the HA RD Connection Broker servers use SQL to store deployment settings (for more info, please see the following post). There are several HA models for SQL that customers can choose to build an e2e HA brokering.

Please note that the load on the SQL virtual machine is very small, about ~3% CPU and very little I/O. This means that we can easily host more virtual machines or handle faster logons.

SQL configuration

• 4 vCPUs, 8192 GB (~6 GB free, only ~2 GB used)
• 2000 connections in one hour
• SQL virtual machine running on R720s

Load on the HA RD Connection Broker server

Similarly, the CPU load on the RD Connection Broker server is ~2%, which means that we have plenty of CPU to handle user logons at a faster rate.

RD Connection Broker configuration

• 2 vCPUs, 8192 GB (~6 GB free, only 2 GB used)
• Broker virtual machines running on R720s

Following is the CPU and storage load on one of the 14 VDI hosts.

As you can see, the CPU consumption is about 75% with 150 virtual machines running the VSI medium workload.

The per-host local storage consists of 10×300 GB SAS 6 Gbps 15K disks configured as RAID1+0, easily handling the necessary IOPS.

For a tighter logon period, our recommendation is to replace one or two of the spindles with a small size SSD (for the virtual desktop template), as the I/O load during a shorter logon cycle can exceed I/O capacity of the local spindle-disks.

It is hard to say exactly when, but a good rule of thumb is to estimate I/O capacity of the 10-disk array at about 2000 read-IOPS and 1000 write-IOPS, and since the I/O load from 150 virtual machines over an hour-long logon period is about 1743, the same workload at about 30 minutes will be about 3500 IOPS, exceeding the I/O capability of the local array.

A 250-GB SSD for the virtual desktop template should easily provide the additional performance necessary for faster logons under a heavier workload.

And finally, let’s take a look at the memory consumption of a single virtual machine.

In the following chart, we see that a guest-VM is running/idling initially at about ~800 MB; CPU is pretty flat too. Then at about 11:25 AM (marked by the vertical green line), a user logon completes and moments later the VSI workload starts running. When benchmarking starts, we see that CPU usage picks up and so does the memory usage, where Hyper-V’s Dynamic Memory provides additional RAM, and finally the guest RAM settles to about 1 GB. This pattern repeats for all virtual machines on a VDI host where about 150 GB of memory is consumed by the 150 virtual machines at a cumulative CPU usage of about 75% CPU. We have plenty of headroom for CPU spikes and real world workload that could demand more memory as each server is configured with 256 GB of RAM (but remember that some portion of the 256 GB of RAM is reserved for the services running in the parent partition).

This post should help customers that are looking to set up a modular and scalable VDI solution, bringing deeper insight into some of the key performance and resource requirements that help the planning of large scale deployments.

Ara Bernardi

RDS Team

Remote Desktop Services (Terminal Services) Team Blog

“Sony gave the PS4 50% more raw shader performance, plain and simple (768 SPs @ 800MHz vs. 1152 SPs & 800MHz). Unlike last generation, you don’t need to be some sort of Jedi to extract the PS4′s potential here. The Xbox One and PS4 architectures are quite similar, Sony just has more hardware under the hood. We’ll have to wait and see how this hardware delta gets exposed in games over time, but the gap is definitely there. The funny thing about game consoles is that it’s usually the lowest common denominator that determines the bulk of the experience across all platforms. On the plus side, the Xbox One should enjoy better power/thermal characteristics compared to the PlayStation 4. Even compared to the Xbox 360 we should see improvement in many use cases thanks to modern power management techniques.” AnandTech does its usual in-depth thing.
OSNews

For this week’s episode of Founder Stories, I sat down with Ilya Sukhar, co-founder and CEO of Parse. The interview was taped days before Parse was acquired by Facebook last month. Parse is a cloud app platform that provides a set of SDKs that enable developers to focus on the execution of their application instead of rebuilding backend functionality for every mobile platform. Sukhar shares his experience of leaving Salesforce after his first startup, Etacts, was acquired and going through Y Combinator for the second time.

Sukhar, who entered YC as a solo founder, was connected to co-founder Kevin Lacker through Paul Graham. The duo then joined up with another co-founding team about a month into YC to build Parse.

“It was a big risk,” says Sukhar. “The founding relationship is a really deep one and there’s a lot of ups and downs to go through together.” Having only known his co-founders for a short time before deciding to work together, Ilya explains the risks and reality of starting a company with strangers. “It worked out well for me but I would not recommend it to other folks.”

In the later half of our discussion, Sukhar explains how he uses arguing tactics to learn whether an employee is a good fit and why stepping back from coding to focus on under-staffed areas of the company has given him the opportunity to learn more about each role before hiring someone to fill it.

Editor’s Note: Michael Abbott is a general partner at Kleiner Perkins Caufield & Byers, previously Twitter’s VP of Engineering, and a founder himself. Mike also writes a blog called uncapitalized. You can follow him on Twitter @mabb0tt.

TechCrunch

Hi all, I’m Travis Howe, a developer on the Remote Desktop Virtualization team. Today I’d like to talk about a few improvements that we made to the RemoteApp and Desktop Connections feature in Windows Server 2012: support for default connections and file type associations.

Default connections

When we added the RemoteApp and Desktop Connections feature in Windows Server 2008 R2 and Windows 7, many administrators wanted to be able to push connections to their users by using Group Policy. To help enable this, we supported a “silent install” API that allowed a user to be signed up for a connection without any prompts. Administrators had to push something like this script on Script Center to their users by using Group Policy.

In Windows Server 2012 and Windows 8, we improved this scenario. We have added a new Group Policy container under “Remote Desktop Services” called “RemoteApp and Desktop Connections,” and within that container have defined a new policy setting called “Specify default connection URL.” Enabling this policy setting causes users to be subscribed to RemoteApp and Desktop Connection at the specified URL. RemoteApp and Desktop Connections that have been installed by using this policy setting have a special name: default connections.

There are a few differences between default connections and ordinary connections:

• On a given machine, a user can only have one default connection.
• Default connections cannot be removed by using the Control Panel UI (the “remove” button does not exist for default connections). The only way to remove them is by changing the Group Policy setting.
• Default connections are able to install file type associations.

Support for file type associations is a somewhat deep subject, so I’ll spend the rest of this post talking about it in more detail.

One more note about default connections: they are unfortunately not supported on pre-Windows 8 clients. That means, if you want to push a RemoteApp and Desktop Connection to end-users running Windows 7 PCs, you must continue to use the script-based approach.

File type associations support: what does it mean?

So what do I mean when I say that default connections are able to install file type associations? When an administrator is publishing RemoteApp programs, they can also choose to publish file types that should be associated with that program. Then, when the RemoteApp program is installed as part of a default connection, we associate the RemoteApp program with those file types on the client machine.

The next time the user tries to open a file of that type, the standard Windows 8 file type association behavior will be used to determine which of the registered programs should be used to open the file. Often, the user will be given a choice. For example, if Microsoft Paint has been published as a RemoteApp program with the .bmp file type association, the user is presented with the following options.

There is one caveat with this feature: when deciding which file type associations to publish for a RemoteApp program, administrators can only choose from a list of available file types for that app. We calculate this list based upon the file types that the app is associated with on the collection endpoints (Remote Desktop Session Host servers in a session collection, or virtual desktops in a virtual desktop collection). This is necessary because when you double-click a file that is associated with a RemoteApp program, the endpoint also needs to know how to open that file type with that program. As a rule, it doesn’t have that information for arbitrary file types. As a result, we do not support associating RemoteApp programs with arbitrary file types on the client.

So, how exactly does one publish file type associations?

Publishing file type associations using UI

As I mentioned earlier, when a RemoteApp program is published, we calculate the list of file type associations that it can support when running as a RemoteApp program. To see this list, open up the properties of a published RemoteApp program in the new Server Manager UI, and navigate to the File Type Associations tab:

In the previous screenshot you can see the list of file types that Paint is capable of launching as a RemoteApp program. To publish file type associations for this RemoteApp program, simply select the file types that you want to be made available to end-users and click OK or Apply.

After you have published file type associations for your apps, they will automatically be installed for all users who are subscribed to the RemoteApp and Desktop Connection as a default connection. That installation will happen the next time the user’s client updates the connection (by default it updates every night around midnight).

Publishing file type associations using the Remote Desktop Services module for Windows PowerShell

This feature can also be managed by using the Remote Desktop Services module for Windows PowerShell. After loading the RemoteDesktop module by typing import-module RemoteDesktop, you can get the list of file type associations available to be published for a RemoteApp program by using the Get-RDFileTypeAssociation cmdlet:

PS C:\Windows\system32> import-module RemoteDesktop
PS C:\Windows\system32> Get-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint

CollectionName       AppAlias   FileExtension  IsPublished
--------------       --------   -------------  -----------
Test                 mspaint    .bmp           False
Test                 mspaint    .dib           False
Test                 mspaint    .emf           False
Test                 mspaint    .rle           False
Test                 mspaint    .wmf           False

In the previous code sample we again see the list of file types that Paint is capable of launching as a RemoteApp program. To publish a file type association for this RemoteApp program, use the Set-RDFileTypeAssociation cmdlet:

PS C:\Windows\system32> Set-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint -FileExtension .bmp -IsPublished $  true
PS C:\Windows\system32> Get-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint -FileExtension .bmp

CollectionName       AppAlias   FileExtension  IsPublished
--------------       --------   -------------  -----------
Test                 mspaint   

Now we have published the file type association for “.bmp” files.

I hope this overview has been helpful and that now you have a better understanding of what makes the default RemoteApp and Desktop Connection different, and how you can leverage it to publish file type associations for your RemoteApp programs.

Remote Desktop Services (Terminal Services) Team Blog

Welcome back!  Kim Nichols here once again with the much anticipated Part 2 to Circle Back to Loopback.  Thanks for all the comments and feedback on Part 1.  For those of you joining us a little late in the game, you’ll want to check out Part 1: Circle Back to Loopback before reading further.

In my first post, the goal was to keep it simple.  Now, we’re going to go into a little more detail to help you identify and troubleshoot Group Policy issues related to loopback processing.  If you follow these steps, you should be able to apply what you’ve learned to any loopback scenario that you may run into (assuming that the environment is healthy and there are no other policy infrastructure issues).

To troubleshoot loopback processing you need to know and understand:

1. The status of the loopback configuration.  Is it enabled, and if so, in which mode?
2. The desired state configuration vs. the actual state configuration of applied policy
3. Which settings from which GPOs are “supposed” to be applied?
4. To whom should the settings apply or not apply?
1. The security filtering requirements when using loopback
2. Is the loopback setting configured in the same GPO or a separate GPO from the user settings?
3. Are the user settings configured in a GPO with computer settings?

What you need to know:

Know if loopback is enabled and in which mode

The first step in troubleshooting loopback is to know that it is enabled.  It seems pretty obvious, I know, but often loopback is enabled by one administrator in one GPO without understanding that the setting will impact all computers that apply the GPO.  This gets back to Part 1 of this blog . . . loopback processing is a computer configuration setting. 

Take a deep cleansing breath and say it again . . . Loopback processing is a computer configuration setting. 

Everyone feels better now, right?  The loopback setting configures a registry value on the computer to which it applies.  The Group Policy engine reads this value and changes how it builds the list of applicable user policies based on the selected loopback mode.

The easiest way to know if loopback might be causing troubles with your policy processing is to collect a GPResult /h from the computer.  Since loopback is a computer configuration setting, you will need to run GPResult from an administrative command prompt.

The good news is that the GPResult output will show you the winning GPO with loopback enabled.  Unfortunately, it does not list all GPOs with loopback configured, just the one with the highest precedence. 

If your OU structure separates users from computers, the GPResult output can also help you find GPOs containing user settings that are linked to computer OUs.  Look for GPOs linked to computer OUs under the Applied GPOs section of the User Details of the GPResult output. 

Below is an example of the output of the GPResult /h command from a Windows Server 2012 member server.  The layout of the report has changed slightly going from Windows Server 2008 to Windows Server 2012, so your results may look different, but the same information is provided by previous versions of the tool.  Notice that the link location includes the Computers OU, but we are in the User Details section of the report.  This is a good indication that we have loopback enabled in a GPO linked in the path of the computer account. 

   
Understand the desired state vs. the actual state

This one also sounds obvious, but in order to troubleshoot you have to know and understand exactly which settings you are expecting to apply to the user.  This is harder than it sounds.  In a lab environment where you control everything, it’s pretty easy to keep track of desired configuration.  However, in a production environment with potentially multiple delegated GPO admins, this is much more difficult. 

GPResult gives us the actual state, but if you don’t know the desired state at the setting level, then you can’t reasonably determine if loopback is configured correctly (meaning you have WMI filters and/or security filtering set properly to achieve your desired configuration). 

     
Review security filtering on GPOs

Once you determine which GPOs or which settings are not applying as expected, then you have a place to start your investigation. 

In our experience here in support, loopback processing issues usually come down to incorrect security filtering, so rule that out first.

This is where things get tricky . . . If you are configuring custom security filtering on your GPOs, loopback can get confusing quickly.  As a general rule, you should try to keep your WMI and security filtering as simple as possible - but ESPECIALLY when loopback is involved.  You may want to consider temporarily unlinking any WMI filters for troubleshooting purposes.  The goal is to ensure the policies you are expecting to apply are actually applying.  Once you determine this, then you can add your WMI filters back into the equation.  A test environment is the best place to do this type of investigation.

Setting up security filtering correctly depends on how you architect your policies:

1. Did you enable loopback in its own GPO or in a GPO with other computer or user settings?
2. Are you combining user settings and computer settings into the same GPO(s) linked to the computer’sOU?

The thing to keep in mind is that if you have what I would call “mixed use” GPOs, then your security filtering has to accommodate all of those uses.  This is only a problem if you remove Authenticated Users from the security filter on the GPO containing the user settings.  If you remove Authenticated Users from the security filter, then you have to think through which settings you are configuring, in which GPOs, to be applied to which computers and users, in which loopback mode….

Ouch.  That’s LOTS of thinking!

So, unless that sounds like loads of fun to you, it’s best to keep WMI and security filtering as simple as possible.  I know that you can’t always leave Authenticated Users in place, but try to think of alternative solutions before removing it when loopback is involved. 

Now to the part that everyone always asks about once they realize their current filter is wrong – How the heck should I configure the security filter?!

Security filtering requirements:

1. The computer account must have READ and APPLY permissions to the GPO that contains the loopback configuration setting.
2. If you are configuring user settings in the same GPO as computer settings, then the user and computer accounts will both need READ and APPLY permissions to the GPO since there are portions of the GPO that are applicable to both.
3. If the user settings are in a separate GPO from the loopback configuration setting (#1 above) and any other computer settings (#2 above), then the GPO containing the user settings requires the following permissions:  

Merge mode requirements (Vista+):

Replace mode requirements:

Tools for Troubleshooting

The number one tool for troubleshooting loopback processing is your GPRESULT output and a solid understanding of the security filtering requirements for loopback processing in your GPO architecture (see above).

The GPRESULT will tell you which GPOs applied to the user.  If a specific GPO failed to apply, then you need to review the security filtering on that GPO and verify:

• The user has READ and APPLY permissions
• Depending on your GPO architecture, the computer may need READ or it may need READ and APPLY if you combined computer and user settings in the same GPO.

The same strategy applies if you have mysterious policy settings applying after configuring loopback and you are not sure know why.  Use your GPRESULT output to identify which GPO(s) the policy settings are coming from and then review the security filtering of those GPOs. 

The Group Policy Operational logs from the computer will also tell you which GPOs were discovered and applied, but this is the same information that you will get
from the GPRESULT.

Recommendations for using loopback

After working my fair share of loopback-related cases, I’ve collected a list of recommendations for using loopback.  This isn’t an official list of “best practices”, but rather just some personal recommendations that may make your life easier.  ENJOY!

I’ll start with what is fast becoming my mantra: Keep it Simple.  Pretty much all of my recommendations can come back to this point.

1. Don’t use loopback   

OK, I know, not realistic.  How about this . . . Don’t use loopback unless you absolutely have to. 

• I say this not because there is something evil about loopback, but rather because loopback complicates how you think about Group Policy processing.  Loopback tends to be configured and then forgotten about until you start seeing unexpected results. 

2. Use a separate GPO for the loopback setting; ONLY include the loopback setting in this GPO, and do not include the user settings.  Name it Loopback-Merge or Loopback-Replace depending on the mode.

• This makes loopback very easy to identify in both the GPMC and in your GPRESULT output.  In the GPMC, you will be able to see where the GPO is linked and the mode without needing to view the settings or details of any GPOS.  Your GPRESULT output will clearly list the loopback policy in the list of applied policies and you will also know the loopback mode, without digging into the report. Using a separate policy also allows you to manage the security of the loopback GPO separately from the security on the GPOs containing the user settings.

3. Avoid custom security filtering if you can help it. 

• Loopback works without a hitch if you leave Authenticated Users in the security filtering of the GPO.  Removing Authenticated Users results in a lot more work for you in the long run and makes troubleshooting undesired behaviors much more complicated.

4. Don’t enable loopback in a GPO linked at the domain level!

• This will impact your Domain Controllers.  I wouldn’t be including this warning, if I hadn’t worked several cases where loopback had been inadvertently applied to Domain Controllers.  Again, there isn’t anything inherently wrong with applying loopback on Domain Controllers.  It is bad, however, when loopback unexpectedly applies to Domain Controllers.
• If you absolutely MUST enable loopback in a GPO linked at the domain level, then block inheritance on your Domain Controllers OU.  If you do this, you will need to link the Default Domain Policy back to the Domain Controllers OU making sure to have the precedence of the Default Domain Controllers policy higher (lower number) than the Domain Policy.
• In general, be careful with all policies linked at the at the domain level.  Yes, it may be “simpler” to manage most policy at the domain level, but it can lead
  to lazy administration practices and make it very easy to forget about the impact of seemingly minor policy changes on your DCs.
• Even if you are editing the security filtering to specific computers, it is still dangerous to have the loopback setting in a GPO linked at the domain level.  What if someone mistakenly modifies the security filtering to “fix” some other issue.
• TEST, TEST, TEST!!!  It’s even more important to test when you are modifying GPOs that impact domain controllers.  Making a change at the domain level that negatively impacts a domain controller can be career altering.  Even if you have to set up a test domain in virtual machines on your own workstation, find a way to test.

5. Always test in a representative environment prior to deploying loopback in production.

• Try to duplicate your production GPOs as closely as possible.  Export/Import is a great way to do this.
• Enabling loopback almost always surfaces some settings that you weren’t aware of.  Unless you are diligent about disabling unused portions of GPOs and you perform periodic audits of actual configuration versus documented desired state configuration, there will typically be a few settings that are outside of your desired configuration. 
• Duplicating your production policies in a test environment means you will find these anomalies before you make the changes in production.

That’s all folks!  You are now ready to go forth and conquer all of those loopback policies!

Kim “1.21 Gigawatts!!” Nichols

Ask the Directory Services Team

Posted by Travis Green, Product Manager, Google Wallet

Paying back your friends is now as simple as sending an email, whether you’re chipping in for lunch or reimbursing your roommate for your share of the rent.

Google Wallet is now integrated with Gmail, so you can quickly and securely send money to friends and family directly within Gmail — even if they don’t have a Gmail address. It’s free to send money if your bank account is linked to Google Wallet or using your Google Wallet Balance, and low fees apply to send money using your linked credit or debit card.

To send money in Gmail, hover over the attachment paperclip, click the $ icon to attach money to your message, enter the amount you wish to send, and press send.

We’re rolling out this feature over the coming months to all U.S. Gmail users over 18 years old, so keep an eye out for the $ icon in the attachment options. You can also get earlier access if your friends have the feature and send money to you.

To learn more, visit our website.

Gmail Blog

Chromebooks were designed to make computing speedy, simple and secure. For many of you, they have become the perfect, additional (and yes, affordable) computer: ideal for catching up on emails, sharing documents and chatting via Hangouts. We’re tremendously grateful to our partners—Samsung, Acer, Lenovo and HP—for their commitment. The momentum has been remarkable: the Samsung Chromebook has been #1 on Amazon’s bestseller list for laptops every day since it launched 125 days ago in the U.S., and Chromebooks now represent more than 10 percent of notebook sales at Currys PC World, the largest electronics retailer in the U.K.

So what’s next? Today we’re excited to announce our newest laptop—the Chromebook Pixel—which brings together the best in hardware, software and design to inspire the next generation of Chromebooks. With the Pixel, we set out to rethink all elements of a computer in order to design the best laptop possible, especially for power users who have fully embraced the cloud. The philosophy of Chrome has always been to minimize the “chrome” of the browser. In much the same way, the goal of the Pixel is to make the pixels disappear, giving people the best web experience.

Let’s start with the screen. This Chromebook has the highest pixel density (239 pixels per inch) of any laptop screen on the market today. Packed with 4.3 million pixels, the display offers sharp text, vivid colors and extra-wide viewing angles. With a screen this rich and engaging, you want to reach out and touch it—so we added touch for a more immersive experience. Touch makes it simple and intuitive to do things like organize tabs, swipe through apps and edit photos with the tip of your finger.

The Pixel has been engineered with the highest quality components to ensure it’s comfortable to use all day long and meets the needs of demanding power users. The body of the Pixel is made from an anodized aluminum alloy to create a smooth and durable surface; vents are hidden, screws are invisible and the stereo speakers are seamlessly tucked away beneath the backlit keyboard. The touchpad is made from etched glass, analyzed and honed using a laser microscope to ensure precise navigation. The Pixel also has powerful, full-range speakers for crisp sound, a 720p webcam for clear video, and a total of three microphones designed to cancel out surrounding noise.

Other aspects of the Pixel include:

• Speed: Speed has been a core tenet of Chrome and Chromebooks since the beginning. For Pixel, it’s critical that the overall experience, everything from loading webpages to switching between apps, is near instant. Powered by an Intel® Core™ i5 Processor and a solid state Flash memory architecture, the Pixel performs remarkably fast.

• Connectivity: The Pixel has an industry-leading WiFi range thanks to carefully positioned antennas and dual-band support. Long-term evolution (LTE) is engineered directly into the machine, delivering fast connectivity across Verizon’s network, the largest, fastest 4G LTE network in the U.S. (LTE model optional). It also comes with 12 free GoGo® Inflight Internet passes for those times you need to connect while in the air.

• Storage: Since this Chromebook is for people who live in the cloud, one terabyte of Google Drive cloud storage* is included with the Pixel. This enables you to save, access and share photos, videos, documents, and all of your stuff from all of your devices, from anywhere.

Finally, as you’ve come to expect from all Chromebooks, all of your favorite Google products like Search, Gmail, YouTube, Maps and Google+ Hangouts are integrated and just a click away. And since it’s based on Chrome OS, the Pixel boots up in seconds and never slows down, requires almost zero setup or maintenance, and comes with built-in virus protection. Best of all, it stays up to date with automatic updates every few weeks.

If you want to be part of the next step in the Chromebook journey, the Pixel will be available for purchase starting today on Google Play in the U.S. and U.K., and soon on BestBuy.com. The WiFi version ($ 1,299 U.S. and £1,049 U.K.) will start shipping next week and the LTE version ($ 1,449) will ship in the U.S. in April. If you’re interested in a hands-on experience, you can visit select Best Buy (U.S.) and Currys PC World (U.K.) store locations.

It’s one of the most exciting times in the history of personal computing, thanks to a rapid pace of change, innovation and consumer adoption of devices. Our goal is to continue to push the experience forward for everyone, working with the entire ecosystem to build the next generation of Chrome OS devices. We hope you enjoy what’s next.

Posted by Linus Upson, Vice President, Engineering

*You will have 1 TB of free storage for 3 years, starting on the date you redeem the offer on eligible Chrome devices.
Google Chrome Blog

In Exchange 2010, we introduced Retention Tags, a Messaging Records Management (MRM) feature that allows you to manage email lifecycle. You can use retention policies to retain mailbox data for as long as it’s required to meet business or regulatory requirements, and delete items older than the specified period.

One of the design goals for MRM 2.0 was to simplify administration compared to Managed Folders, the MRM feature introduced in Exchange 2007, and allow users more flexibility. By applying a Personal Tag to a folder, users can have different retention settings apply to items in that folder than the default tag applied to the entire mailbox(known as a Default Policy Tag). Similarly, users can apply a different tag to a subfolder than the one applied to the parent folder. Users can also apply a Personal Tag to individual items, allowing them the freedom to organize messages based on their work habits and preference, rather than forcing them to move messages, based on the retention requirement, to an admin-controlled Managed Folder.

You can still use Managed Folders in Exchange 2010, but they’re not available in Exchange 2013.

For a comparison of Retention Tags with Managed Folders and migration details, see Migrate Managed Folders.

If you like the Managed Folders approach of being able to create a folder in the user’s mailbox and configure a retention setting for that folder, you can use Exchange Web Services (EWS) to accomplish something similar, with some caveats mentioned later in this post. You can write your own code or even a PowerShell script to create a folder in the user’s mailbox and apply a Personal Tag to it. There are scripts available on the interwebs, including some code samples on MSDN to accomplish this. For example:

• Stamping Retention Policy Tag using EWS Managed API 1.1 from PowerShell (Exchange 2010)
• 5 Lesser Known Operations in Exchange Web Services on Exchange 2013, Exchange MVP Glen Scales’ post on the MVP Program Blog, which uses a simpler method to do this on Exchange 2013.

Note: The above scripts are examples for your reference. They’re not written or tested by the Exchange product group.

But is it supported?

We frequently get questions about whether this is supported by Microsoft. Short answer: Yes. Exchange Web Services (EWS) is a supported and documented API, which allows ISVs and customers to create custom solutions for Exchange.

When using EWS in your code or PowerShell script to apply a Personal Tag to a folder, it’s important to consider the following:

For Developers

• EWS is meant for developers who can write custom code or scripts to extend Exchange’s functionality. As a developer, you must have a good understanding of the functionality available via the API and what you can do with it using your code/script.
• Support for EWS API is offered through our Exchange Developer Support channels.

For IT Pros

• If you’re an IT Pro writing your own code or scripts, you’re a developer too! Above applies to you.
• If you’re an IT Pro using 3rd-party code or scripts, including the code samples & scripts available on MSDN, TechNet or elsewhere on the interwebs, we recommend that you follow the general best practices for using such code or scripts, including (but not limited to)the following:
  • Do not use code/scripts from untrusted sources in a production environment.
  • Understand what the script or code does. (This is easy for scripts – you can look at the source in a text editor.)
  • Test the script or code thoroughly in a non-production environment, including all command-line options/parameters available in it, before installing or executing it in your production environment.
  • Although it’s easy to change the PowerShell execution policy on your servers to allow unsigned scripts to execute, it’s recommended to allow only signed scripts in production environments. You can easily sign a script if it’s unsigned, before running it in a production environment.

So should I do it?

If using EWSto apply a Personal Tag to custom folders helps you meet your business requirements, absolutely! However, do note and consider the following:

• You’re replicating some of the functionality available via Managed Folders, but it doesn’t turn the folder into a Managed Folder.
• Remember – it’s a Personal Tag! Users can remove the tag from the folder using Outlook or Outlook Web App.
• If you have additional Personal Tags available in your environment, users can change the tag on the custom folder.
• Users can tag individual items with a different Personal Tag. There is no way to enforce inheritance of retention tag if Personal Tags have been provisioned and available to the user.
• Users can rename or delete custom folders. Unlike Managed Folders, which are protected from changes or deletion by users, custom folders created by users or by admin are just like any other (non-default) folder in the mailbox.

Provisioning custom folders with different retention settings (by applying Personal Tags) may help you meet your organization’s retention requirements. As an IT Pro, make sure you understand the above and follow the best practices.

Bharat Suneja

Exchange Team Blog

For the latest and greatest on business intelligence and business analytics, look no further than the PASS Business Analytics Conference, which kicks off today in Chicago. At a time when data is increasingly at the forefront of the industry conversation, this event offers an opportunity to go deep and take a look at how business intelligence and data professionals are using analytics to further their business goals. Are they able to share their insights and tell stories in new ways? What kind of critical thinking and strategy are they employing in their everyday work? Learning how customers are working with data and how we can improve that experience is crucial as we continue to grow and develop our data platform.

The good news is, momentum behind analytics is building, especially at the C-level. For the last two years* in a row, CIOs surveyed by Gartner ranked analytics and business intelligence as their number one technology priority, even over mobile technologies and cloud computing. Furthermore, in Gartner’s 2012 BI Magic Quadrant**, the top two reasons indicated for choosing a particular BI platform provider were functionality (45.5%) and ease of use for end users (42.6%). It’s clear there’s a trend toward broader use of analytics, something we’ve been working toward for years with Microsoft’s data platform. Our goal is to provide technology that enables employees to practice the art of analytics at its highest form: anticipating both business opportunities and problems with proactive intelligence, data-driven problem solving, and visually compelling, comprehensive story-telling.

Consider what it means for their day-to-day workload if everyone, not just data analysts, had the ability to run their own queries and present them in a way that can drive decision-making and impact their organizations’ bottom-line. By creating a connected experience and integrating BI capabilities into tools people are already using, like Excel, we give more people the opportunity to have – and share – those “aha!” moments that come from data discovery. Through tools like PowerPivot, Power View, project codename “Data Explorer” and others, we democratize that process of taking data and turning it into insight.

If you’re at the PASS Business Analytics Conference this week, stop by the Microsoft booth to check out our demos, and be sure to attend tomorrow’s keynote from Microsoft technical fellow Amir Netz and partner director Kamal Hathi where they will share their perspective on where analytics is going. I’ll be continuing to post some thoughts on the art of analytics here for the remainder of the week:

• Day 2, PASS Business Analytics Conference, New 3D Mapping Analytics Tool for Excel
• Day 3, PASS Business Analytics Conference, Analytics in Action 

Eron Kelly
General Manager
SQL Server

*Gartner, “Hunting and Harvesting in a Digital World: The 2013 CIO Agenda,” by Mark P. McDonald and Dave Aron, January 1, 2013
**Gartner, “User Survey: Customers Rate Their BI Platform Functionality, 2012,” by John Hagerty, August 15, 2012

SQL Server Team Blog