Apple TV and AirPlay become increasingly popular in enterprise and schools recently. However, it can be much more complicated to make AirPlay work smoothly in an enterprise environment than a home network. This article discusses both two parts of AirPlay: Discovery and Streaming.
AirPlay Devices Discovery
Before iOS 7.1, AirPlay Devices rely on Bonjour (which uses mDNS and DNS Service Discovery) to discover AirPlay enabled devices. However, VLAN separation and broadcast/multicast filters, which are commonly used in enterprise networks, prevents AirPlay devices discovery.
Following is a packet capture of the AirPlay mDNS query and response. I allowed mDNS so AirPlay devices in the same VLAN can see each other.
Now, after iOS7.1, AirPlay devices can discover each other using Bluetooth Low Energy (BTLE) . This is good for enterprise environment because we can block mDNS and still allow Apple TVs to be discovered by Bluetooth, so that a user can only see nearby AirPlay devices.
Previously, AirPlay devices need to be in the same network stream contents.
Now, using peer-to-peer AirPlay, we can stream contents from an iOS device or Mac to Apple TV even if the devices are on different networks or there’s no network available.
To support peer-to-peer AirPlay, you need to meet the following requirements:
1. Client needs to be at least iOS8 and MacOS 10.10
2. Apple TV needs to be at least 2nd generation (model A1469 above) and tvOS 7.0
I tried a 1st generation Apple TV with tvOS 8.4.2 but it still requires same VLAN for AirPlay streaming (though it can be discovered by Bluetooth).
According to Apple , peer-to-peer AirPlay causes the devices to visit Wi-Fi channel 149(80MHz) or 44 in the 5 GHz band and Wi-Fi channel 6 in the 2.4 GHz band, where the discovery process continues.
Once the user selects an Apple TV and AirPlay starts, the Wi-Fi radios timeshare between channel 149 and whichever infrastructure channel each device is currently using. If possible, the AirPlay sender roams to the same infrastructure channel the Apple TV is using. If neither device is currently using an infrastructure network, the devices will utilize Wi-Fi channel 149 only for AirPlay. Peer-to-peer mirroring adheres to 802.11 standards, sharing Wi-Fi bandwidth with other Wi-Fi devices. 
This is where it becomes interesting. In an enterprise environment using VLAN separation, peer-to-peer AirPlay allows client devices (maybe on staff or guest VLAN) stream to Apple TVs (maybe on AV VLAN or even no network). However, the client device’s airtime is reduced because it needs to jump to channel 149 to send data to Apple TV. A bigger problem is interference with all nearby WiFi devices if your WiFi infrastructure uses DFS channels 149, 153, 157 or 161.
I am lucky to have several Apple TVs to perform some tests. My laptop is on a staff VLAN and all the Apple TVs are patched through Ethernet on a dedicated AV VLAN.
As can be seen in the following 3 figures, AirPlay uses an 80MHz channel spanning 149, 153, 157 and 161. In Figure 2, where my MacBook is using channel 153, AirPlay definitely causes co-channel interference.
More interestingly, I found in several cases, as shown in Figure 4, Apple TV uses an additional 80MHz channel spanning 36, 40, 44 and 48. As can be seen in the waterfall plot in Figure 4, I tried stop-start AirPlay several times to confirm it is indeed AirPlay using these channels. In addition, I also did a packet capture over the 80MHz channel spanning 36, 40, 44 and 48, showing data transmission from my MacBook to Apple TV, as shown in Figure 5.
In an enterprise environment, we can keep using VLAN separation and mDNS filtering. Apple TVs can be discovered by Bluetooth and streamed using peer-to-peer AirPlay.
The advantages are obviously that we keep network securely segmented, allow users to see only nearby Apple TVs and allow AirPlay between devices on different VLANs.
The disadvantage is WiFi channel interference.
The suggestions for deploying Apple TVs on a large enterprise Wi-Fi network:
- Patch Apple TV in with ethernet cable, allow traffic between user vlans and Apple TV vlan, if you cannot do this, see following suggestions
- Don’t use WiFi channel 149, 153, 157 and 161 for your infrastructure network nearby Apple TVs (also avoid WiFi channels 36, 40, 44 and 48 if possible)
- Don’t place or mount the Apple TV behind objects that could disrupt the Bluetooth Low Energy and Wi-Fi signals
- Don’t use 2.4G channel 6 (actually don’t use 2.4G at all as there are many interference sources)
 iOS Deployment Reference
 Apple TV Peer-to-Peer using WiFi channels 6 and 149
 Enterprise Best Practices for iOS devices and Mac computers on Cisco Wireless LAN
 Apple TV and iOS Client instability issues
 Apple TV discovery over Bluetooth
 Apple AirPlay Capture
In Exchange 2010 and 2013, when you configure “send as” and “send on behalf” for a mailbox or shared mailbox, by default the sent emails are only copied to sender’s sent box but not from’s mailbox.
If multiple persons have access to the same mailbox or shared mailbox, they may want to see the email/reply sent by other persons so that they are aware of the status/conversation.
To copy sent emails to both sender and from mailbox:In Exchange 2010:PowerShell1Set-MailboxSentItemsConfiguration JZ@example.com -SendAsItemsCopiedTo SenderAndFromIn Exchange 2013:PowerShell1Get-Mailbox JZShared | Set-Mailbox -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true