Active Directory, Exchange, Microsoft, Office 365, PowerShell

How to Provision Exchange Online Mailboxes

After completing a migration to Exchange Online, it is common to have questions like:

1) What is the best practice for provisioning mailboxes?

2) How do I provision mailboxes?

3) Why should I keep this Exchange server around?

Well, these are good questions.  Let’s start with the last question.  When an organization migrates to Exchange Online, it is quite commonly thought that Exchange is no longer needed on-premise.  From a deeply technical perspective, this is true… but it is a bad idea.  As a matter of fact, it is such a bad idea that I wrote a very blunt response to another blog post suggesting that keeping hybrid in place is not really necessary.  Well, if you want to live in a world where you are maintaining your own tools, have only skilled individuals provisioning mailboxes, or you have lesser skilled folks poking around directly with Active Directory attributes, knock yourself out.  Also, this doesn’t apply to organizations that don’t synchronize their on-premise Active Directory to Azure AD.  For those that want to limit their heartburn and remain in a supported configuration, however, you must not only keep an on-premise Exchange server, but also keep it in a hybrid configuration.

Microsoft goes a long way to explain it in their article: How and when to decommission your on-premises Exchange server in a hybrid deployment.

The problem is that this article is buried deeply out there in the web and very hard to find.  Microsoft doesn’t make this very well known because this information is hard to find.  Here is the basic summary: You need to keep an Exchange server around on-premises in hybrid not because of Exchange, but because of directory synchronization.  AAD Connect (and its predecessors AAD Sync and DirSync) is built on what is now know as Microsoft Identity Manager 2016.  This is a metadirectory product that helps to synchronize and provision identities.  While there can be some bi-directional synchronization of attributes, there has to be an ultimate source of truth.  This means that when you are synchronizing to Azure AD, your on-premises Active Directory is that source of truth.  Users must be provisioned there and many attributes must also be maintained there.  Since these objects, like mailboxes, distribution groups, and mail contacts, must exist in on-premises Active Directory, it makes sense to have an administrative interface.  One could manually edit the attributes like ProxyAddresses and know that the primary SMTP address should be meet the following requirements:

1) Be prefixed with “SMTP:”

2) Be unique throughout your organization

3) Have its value saved to the Mail attribute

Other values in ProxyAddresses should be prefixed with “smtp:” or their address type prefix.  Because of these challenges, Microsoft has made it a support requirement that Exchange remain on-premises.  In fact, they have made it easier by giving all enterprise Office 365 customers a free license key for use with hybrid co-existence servers.

Aside from the support requirement, there are plenty of reasons to keep an Exchange server on-premise.  First, it makes support magnitudes more simple.  You can use the on-premises RBAC model and grant support staff the rights to provision recipients from your Exchange system without even granting rights to Office 365 or Exchange Online administratively.  Another big reason is that Exchange Online does NOT have Email Address Policies.  By maintaining a hybrid co-existence server, Email Address Policies can be established and executed there and the subsequent AD writes will be synchronized to Azure AD, this giving you Email Address Policies for Exchange Online recipients.  Finally, many time you need to relay mail from on-premises devices and applications; this is far easier if it is done centrally from a server on-premises that is granted relay rights through Exchange Online.  This simplifies firewall rules and keeps the configuration within Exchange Online to a minimum.  This relay point may as well be the hybrid co-existence server that you should already have.  Servers with hybrid co-existence perform Exchange Authentication and have a privileged existence from the standpoint of spam filtering.  Finally, if you take the server out of the topology by not keeping it in hybrid configuration, you lose access to many of the cmdlets and web interface means to properly provision recipients in Exchange Online.

Now we know why we should maintain this server, but how do we effectively utilize it?  Well, it is not a walk in the park unless you are well-acquainted with Exchange Management Shell.  Microsoft has been very inconsistent about its tools.  In the web interface, you can create a User Mailbox in Exchange Online from your on-premises server if you create a new Active Directory user account at the same time, but you cannot use an existing user account.  Also, Microsoft makes it easy to create Equipment and Room mailboxes, which are types of Shared mailboxes, but not Shared mailboxes themselves.  Microsoft recommends that you create a Shared mailbox on-premises and migrate it to Exchange Online.  This is just bad, Microsoft… you should fix this and make it work well and consistently.

Here is my cheat sheet for provisioning mailboxes and it requires Exchange Management Shell connected to the on-premises environment.  These commands count on existing AD user objects.  Let’s assume that we have the following AD user objects for which we must create Exchange Online mailboxes with their intuined types:

User Mailbox (AD user object name: “User Mailbox”):

1. From Exchange Management Shell: Get-User “User Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com

2. Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta

Room Mailbox (AD user object name: “Room Mailbox”):

1. From Exchange Management Shell: Get-User “Room Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com

2. From Exchange Management Shell: Get-RemoteMailbox “Room Mailbox: | Set-RemoteMailbox -Type Room

3. Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta

Equipment Mailbox (AD user object name: “Equipment Mailbox”):

1. From Exchange Management Shell: Get-User “Equipment Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com

2. From Exchange Management Shell: Get-RemoteMailbox “Equipment Mailbox” | Set-RemoteMailbox -Type Equipment

3. Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta

Shared Mailbox (AD user object name: “Shared Mailbox”):

1. From Exchange Management Shell: Get-User “Shared Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com

2. Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta

3. From Exchange Online PowerShell: Get-Mailbox “Shared Mailbox” | Set-Mailbox -Type Shared

That’s it.  Distribution groups are created on-premises just like normal and members added from on-premises.  Mail contacts are also created just like normally on-premises.  Each of these synchronize properly to Azure AD.

Ensuring that you properly provision your mailboxes on-premises means that messages relayed from on-premises devices and applications do not get NDRs and that email addresses get assigned via policies, reducing the opportunity for human error.  One thing to keep note of is that Shared mailboxes are still inconsistent from the rest; they are created as regular mailboxes and then converted to Shared mailboxes in Exchange Online directly.  I wish Microsoft would change this as it is possible… if you manually set the msExchRecipientDisplayType and msExchRecipientTypeDetails attributed to the proper values, they will be provisioned in Exchange Online properly, but this should be a requirement.

Active Directory, Microsoft, Office 365

Azure Active Directory Identities

This post is an introductory post in an upcoming and unfolding series regarding identity management.

Whether for Office 365, Dynamics CRM, Azure, or 3rd party apps, having an understanding of identities in Azure AD is a must have feather to have in your cap.  These different identities require some decisions early on that are rather critical and based on core requirements that should be defined by business and security policies within your organization.  The first thing to understand about Azure AD is that it is NOT a domain controller in the cloud.  In fact, it isn’t operating on Active Directory Domain Services at all.  For approaching 20 years, we have generally used “Active Directory” to mean what is now properly defined as Active Directory Domain Services (AD DS), but that was originally the proper name for the on-premise identity management service from Microsoft.  This changed rather early in Active Directory’s life with the release of Windows Server 2008 as Active Directory became an umbrella for many on-premise services.  With Windows Server 2003, Active Directory Application Mode (ADAM) was released, which was a generic LDAP implementation from Microsoft built off of the same core components of Active Directory, but without many of the adjacent components, like Kerberos, Group Policy, time services, etc.  ADAM became known as Active Directory Lightweight Directory Services (AD LDS) with the release of Windows Server 2008.  Other services include Active Directory Certificate Services (AD CS) and Active Directory Federation Services (AD FS).

Notably, it is AD LDS that is important to us in our understanding of Azure AD because it is the underlying technology upon which Azure AD is built.  Azure AD does not have Kerberos, Group Policy, or time services.  Further, Office 365 and Azure services are not joined to Azure AD; rather, they have their own AD DS forests (and many of them) to which Azure AD objects are synchronized.  One item of note: things in the cloud change like Midwestern weather, if you don’t like it, wait 5 minutes; there is a product that is early in its life known as Azure AD Domain Services, but it is not without many compromises and has a long way to go.

So, why implement Azure AD?  There are numerous reasons and they align with the reasons that organizationed implemented Active Directory in the first place.  The old story was that of consolidating identities in an era when there was plenty of “identity sprawl” on-premise.  We had largely conquered that problem, but it has resurfaced in the cloud era.  Now, we have multiple identities for various cloud services.  Managing multiple identities is a very real problem.  First, IT organizations have to create these numerous identities and manage them for all of their users; it is tedious, error prone, and requires more knowledge of security in each system.  Second, end users have to utilize and recall the identities and credentials for each system; this leads to password reuse, passwords that are too simple, and/or writing passwords down.  These are all bad practices, but if we expect our end users to live in an environment with ever growing lists of identities, we’re asking for it to happen.  While Azure AD is the core identity management platform for Microsoft cloud services, and it is the logical starting point for its implementation, Azure AD is much more than that.  So, here is a list possibilities that is far from conclusive:

1. Office 365: this is the main gateway to Azure AD consumption.  You plan to implement all or some of the services in Office 365 or perhaps even just deploy the Office 365 ProPlus software package for end users.

2. Exchange Online Protection and/or Exchange Online Archiving: perhaps you have an existing message hygeine service and you are looking to replace it with EOP, or you have the special license that gives you EOP and the Exchange Online Archiving feature.

3. Dynamics CRM: Microsoft’s customer relationship management software offered as a service.

4. Azure: Infrastructure as a Service and Platform as a Service offerings from Microsoft.

5. Azure AD Marketplace: over 3000 applications from 3rd parties already integrated for use within Azure AD, including Salesforce, ServiceNow, GoToMeeting, WebEx, Concur, Egencia, and even G Suite (formerly Google Apps) and AWS.

6. Azure AD B2C: develop your own applications that integrate into Azure AD and Microsoft Accounts (consumer accounts).

So, a fairly compelling list, especially considering that it supports competing cloud products.  What are the first things that you need to understand and decide when you have set the path to implement Azure AD?  First and foremost, there are three types of identities in Azure AD: Cloud-only, Managed (or Synchronized), and Federated.

Cloud-only: this is the simplest model to implement and requires absolutely no additional infrastructure.  An administrator logs into Azure AD and creates identities directly in Azure AD.  This is straight forward and easily implemented for smaller organizations, but it only adds another identity and does not consolidate them.  It is prone to all of the same issue we are trying to solve by consolidating identities… administrative overhead, errors, and end user problems with multiple identities.

Managed (or Synchronized): this is the most common identity type in new implementations.  It requires that a single system be deployed with AAD Connect, a free product from Microsoft for synchronizing on-premise identities to Azure AD.  You can synchronize password hashses and have same sign on (not quite the same as single sign on, but offers perhaps 80% of the benefits).  This is a prerequisite for the next type.

Federated: this provides the most robust set of features and requires the most infrastructure.  First, you must implement AAD Connect, then you install a federation infrastructure that is usually 8 systems in a minimal best practice setup that is defined by two locations with separate internet connections using two load balanced proxy servers in each location in front of two load balanced AD FS servers in each location.  The reason for this is that if your federation infrastructure is unavailable, nobody signs into Azure AD.  This price comes with some fairly compelling value for those that require it: Multi-Factor Authentication, real-time accounts disablement, real-time password updates, network location restrictions, time of day restrictions, and true single sign on (SSO).  This was initially the most popular means to implement identities in Azure AD, but over time these requirements have slowly been eroded by capabilities in AAD Connect and Azure AD Premium (which requires an additional subscription).
It is worth noting that there are numerous 3rd parties that offer competing federation solutions for Azure AD.  They have licensing fees and combined account for only 3% of all identities in Azure AD.  For a supportability and simplicity standpoint, it makes sense to implement something that more of a known quantity… you will more readily find administrators that are familiar with the Microsoft offerings and there is a significantly larger body of knowledge available online to support it.  Noteable 3rd party federation providers include: Okta, OneLogin, PingFederate, and Oracle.


Azure AD Premium is a subscription-based offering from Microsoft that offers many of the features available with federated identities without the need for a federation infrastructure, including: Multi-Factor Authentication, network location restrictions, time of day restrictions, and a self-service password reset portal.  Combined with a new feature in AAD Connect called Pass-Thru Authentication (currently in preview), one could have nearly all of the capabilities of a federated infrastructure, including SSO.

The next thing to understand is how users sign in and the surrounding best practices.  The username used in Azure AD is the UserPrincipalName (UPN); it looks like an email address.  Within AD DS, this would be like username@activedirectorydomain.  The first issue here is that many organizations have not aligned their Active Directory domain names with their public domain names, which is a requirement since we are using an internet-based service… you aren’t going to be using a “domain.local” option.  You can rectify this by implementing an Alternate UPN Suffix in Active Directory Domains and Trusts.  The ultimate best practice is to have UPNs match the primary email address of a user, because most users won’t know what a UPN is but they will know what an email address is and Microsoft has labelled the username fields as “email address.”  This is almost never an issue for organizations because UPNs are rarely utilized on-premise.

Before going down the path to implement Azure AD, it is worth executing IdFix, a free utility from Microsoft to identify common issues that should be remediated before installing AAD Connect.  Common issues includes duplicate values within your domain for fields that should be unique and invalid characters.  The tool makes a recommendation on how to remediate and can fix the issue for you, but it is worth reviewing the recommendations and findings and remediating them yourself and then execute the tool again to determine if things have been addressed.

Exchange, Microsoft, Office 365

Potential Litigation Hold Loopholes and How to Avoid Them

One long standing feature of how Microsoft Exchange works has recently changed: where “Sent Items” reside when you “Send As” another recipient.  The traditional flow is that if “User A” has privileges to “Send As” “User B”, then the message would go in the “Sent Items” folder of “User A”.  This changed with Exchange Server 2013 CU9 and Exchange Online with the following: Want more control over Sent Items when using shared mailboxes.  Fortunately, this feature is disabled by default and things work the same as the original method, and I will explain why this is a good thing below.

So here is the issue: shared mailboxes do not require a license.  The rationale from Microsoft is that you license users and a shared mailbox can only be access by a licensed user via their own user mailbox.  This is great for customers because they can create these shared mailboxes and allow groups of users to share the mailbox and respond to messages.  However, since it isn’t licensed, the mailbox lacks many features: Online Archive, Retention Policies, and In-Place/Legal Holds.

So, this causes two issues:

1) There are no backups in Exchange Online and the easy way to manage this is to use the underlying resiliency of Exchange Native Data Protection and implement Online Archive (with unlimited space in Exchange 2016, assuming you have the storage to support this, and Exchange Online), Retention Policies to move messages to the Online Archive, and In-Place/Legal Hold to make the messages immutable.  This means that if a user deletes a message, it ages out of the Deleted Items Retention, and you implement In-Place/Legal Hold for 6 months, 1 year, indefinitely, you can use eDiscovery to find the messages and recover them for the user.  This is a great value when you are already paying for Office 365 and you can eliminate a significant cost related to backups… which can be rather significant just considering email.

2) You have a regulatory or business policy that requires you to retain messages for some period time for legal purposes.  You utilize these same features to defend or litigate.

Now, let’s say you enable the new Sent Items behavior and you fall under one of these scenarios.  And because Shared mailboxes don’t require licenses and customers don’t tend to want to pay for an “unnecessary” license, these messages will not be retained; they are in the “Sent Items” of the Shared mailbox without the capability to have a hold.

This is something that I routinely advocate.  Buy an Exchange Online Plan 2 license for your Shared mailboxes.  It is $8/mailbox/month, significantly cheaper than than buying an Office 365 E3 license listed at $22/user/month.  The Office 365 E3 license includes Exchange Online Plan 2, so it is the same feature set from an Exchange perspective and a Shared mailbox doesn’t need SharePoint, Skype for Business, or Office 365 ProPlus.  This is my minimum recommendation for ALL licensing with Exchange Online if you have any of the above requirements, because Office 365 E1 or less (like kiosk licensing) do not cover you.

Perhaps Microsoft will respond to this gap by allowing for In-Place/Legal Hold for Shared mailboxes based on the number of licenses you hold.  We can hope.

Active Directory, Exchange, Microsoft, Office 365

Learning Microsoft Identity Manager

Microsoft Identity Manager (MIM) is a product with a long history from Microsoft.  While its storied timeline begins many years earlier as a product that Microsoft acquired called ZoomIt Via, Microsoft eventually rewrote the product from the ground up and released it as Microsoft Identity Integration Server 2003.  Since that time, the core component has not significantly changed but the product has picked up new features like a net roaming through the seas.  It is a very important product that has seen popular usage in many applications including GALSync for synchronizing directory objections in multi-forest Exchange environments and ADAMSync for synchronizing directory information from Active Directory Domain Services (AD DS) to Active Directory Lightweight Directory Services (AD LDS), formerly known as Active Directory Application Mode (ADAM).  There are two very timely uses of this product today, Microsoft Exchange EdgeSync Service, used to synchronize valid recipients from AD DS to the AD LDS created for the Edge server role, and Azure Active Directory Connection (AAD Connect), formerly Directory Synchronization (DirSync) and Azure Active Directory Sync (AADSync).  Most recently, the product has been known as Microsoft Forefront Identity Manager (FIM) and finally as Microsoft Identity Manager (MIM) as the current release.

With Microsoft cloud adoption so high, it is rather prudent for IT professionals to become familiar with the inner workings of the product that keeps everything held together.  Unfortunately, there is only one real book out there dedicated to the product, “Microsoft Identity Manager 2016 Handbook” by David Steadman and Jeff Ingalls, released by Packt Publishing.  Now, I am somewhat perplexed by this book because it is quite literally a rebranding of “Microsoft Forefront Identity Manger 2010 R2 Handbook” by Kent Nordström, released by Packt Publishing.  I am really unsure of what has happened behind the scenes, but the publisher has new authors listed for a book and they have written forwards suggesting that they have authored this new book… but it is the same book with some minor updates for the latest release and some additional chapters.  Also, while the narrative approach of this book may appeal to some, it doesn’t appeal to me.  Essentially, a ficticious company has been invented of an indeterminate size with minimal requirements defined… the purpose being that it doesn’t paint itself into a corner with the audience so that readers can perceive that this could be their company.

Now, I am glad that the resource exists, don’t misunderstand me on that account.  However, I have thought that there is a distinct void in regards to this product.  Since the product has had more rebranding than Lync/Skype for Business (which really is a feat), it suddenly hit me that one could search for the previous names of the product for older resources, especially since the core sync service really has changed very little.

This has brought me to chapter 21 of “Active Directory Cookbook”, both the 3rd and 4th editions, by Robbie Allen, et al.  This solitary chapter in each book, discussing Identity Lifecycle Manager 2007 (another previous name of the product) and Forefront Identity Manager 2010, respectively, goes a long way towards explaining the purpose of the product, its unique jargon, and how the process generally works when it comes to integrating identities from various sources.

AAD Connect, and its predecessors, has gone a long way to simplying the process of installing the sync engine and configuring the prerequisites, connectors, and flows of data.  While having this level of simplicity of installation is a great boost for us all, it does mean that few find it necessary to dive deeper into the underying technology that supports it.  Approaching more complex scenarios, like cross-forest migrations, multi-forest relationships with Office 365, and more make this knowledge all the more necessary and beneficial.  Additionally, new features that have inserted themselves through out the years provide additional value that can be leveraged, like self-service password resets and certificate management, and provide a line of vision related to the development of features available in Azure Active Directory today and into the future.

So, what are useful concepts to understand about the product?  Understanding the Connector Space and Metaverse model of synchronization are key.  Also, now that having at least one sync engine in service (AAD Connect) is rather mainstream, knowing that any particular SQL instance can only have a single sync service attached is fairly important; if you utilize a non-local SQL instance for AAD Connect and you require an instance of MIM for some other functionality, they cannot use the same SQL instance.  In terms of licensing, the MIM server license is now included with Windows Server and many operations, namely those that only make use of the sync engine, do not require a client access license; for those tasks that do require a CAL, one is included with each license of the Enterprise Mobility + Security license that encompasses Azure AD Premium, InTune, and Azure Information Protection, among many others.

What are some valuable uses of MIM in an Azure AD and/or Office 365 deployment?  One of the long-lacking features of Azure AD was license provisioning; this has been addressed with the “in preview” feature known as AD Group-based License Management.  However, if your requirements are a bit more complex or it doesn’t seem to fit your needs, you could use MIM to key off of attribute values or group membership to determine the licenses that should be applied and then using the PowerShell Management Agent, it could connect to Azure AD and provision licenses to users.  In addition, there are many “policy” decision-points that could have a true policy model to drive them.  For instance, creating policies for mailbox size (mostly on-premise, but if you want to restrict the very generous offerings in Exchange Online it would also apply) and having MIM do the heavy lifting.  Some other tasks that have some pain points include provisioning mailboxes in Exchange Online in a hybrid configuration.  The tools exist within PowerShell, but they aren’t entirely consistent themselves.  The Exchange Admin Center is far from consistent.  For instance, you can use an existing AD user object to deploy an on-premise mailbox via the EAC, but you cannot do so when deploying an Office 365 mailbox (Remote Mailbox), but this is easy via Exchange Management Shell (e.g. Get-User <Identity> | Enable-RemoteMailbox).  The various shared mailbox types are also an enigma; you can use the same commands to create a Room or Equipment mailbox by following the previous command with an operation to set the type (e.g. Get-RemoteMailbox <Identity> | Set-RemoteMailbox -Type Room), but if you just want a generic shared mailbox, Microsoft recommends to create the mailbox as a shared mailbox on-premise and migrate it to Exchange Online; however, one could connect to Exchange Online PowerShell and set the type to Shared or use the Exchange Online EAC to do the same (e.g. Get-Mailbox <Identity> | Set-Mailbox -Type Shared).  These tasks could be made consistent via MIM by using an Active Directory object to classify the mailbox type and have it provisioned based on those attribute settings.  Other tasks could include creating a standard to change the default calendar permissions for shared mailboxes (or user mailboxes, for that matter) so that they expose additional details.  Your creativity is the limit.

Exchange, Office 365, PowerShell

Identifying Mailboxes without a Cloud Alias

In a hybrid Exchange scenario, mailboxes should be stamped with aliases that are mapped to the tenant unique namespaces (e.g. *.onmicrosoft.com).  If a mailbox does not contain these aliases, it will fail to migrate.  These aliases are normally applied via Email Address Policies, but if the AD object is set to block Email Address Policies from applying, this won’t work.  A quick trick to identify these aliases is as follows (from the Exchange Management Shell, on-premise):
$Mailboxes = Get-Mailbox -ResultSize Unlimited -Filter {EmailAddressPolicyEnabled -eq $False -and EmailAddresses -NotLike "*.onmicrosoft.com"}
Let me know if this works for you in the comments.  Thanks!

Microsoft, PowerShell

Considerations for an Open Sourced PowerShell

PowerShell

With the news that PowerShell has been open sourced and brought to Linux and Mac OSX, we are witnessing the fruits of Microsoft’s journey to embrace other platforms in an effort to reach and support customers’ needs.  It is pretty exciting as my personal journey with technology began on the other side, using Linux and working with open sourced solutions and embracing Microsoft platforms.  We can see this with the release of the Office suite on Android and iOS as an equal release to anything else.

Announcement here: PowerShell is open sourced and is available on Linux

So, what does this all mean for your PowerShell scripts?  There definitely are some considerations.  First, not everything PowerShell is available.  For example, Windows specific commands obviously won’t be available on Linux or Mac OSX.  Other considerations are related to common aliases; like ‘ls’.  This command is aliased to Get-ChildItem in PowerShell.  What problems does this cause?  Well, the PowerShell team decided to not apply this alias in Linux/Mac because it might seem presumptuous.  The recommended action for scripts to be the most portable is to not use aliases.  If you are at the prompt running commands, go ahead and use whatever time savers you have at your disposal, but if you are saving it, use the full cmdlet name.  This is not only good for portability, but it also makes scripts easier read when comparing them to documentation for those not familiar with the alias.

In addition, we are accustomed to the .ps1 extension in Windows, but this doesn’t mean anything in Linux/Mac; files are files.  Those familiar with shell scripting on these platforms will know that the first line of the script denotes what executable should be used to parse the script.  So, PowerShell scripts meant to be portable should use the familiar file extension and the first line beginning with #!/usr/bin/powershell; this will simply be read as a comment on the Windows platform.  This also suggests that if you have only developed or tested for a particular platform, that it might be reasonable to only use the requirement for that platform as a means to communicate its status.

Other items that have not been open sourced are components that belong to other teams.  It will be up to those teams to determine if that is the direction they will take.  For instance, the PowerShell ISE is actually built on top of Visual Studio and the PowerShell team cannot decide to open source it.

PowerShell has been open sourced with the MIT license.

What are your thoughts and concerns?