Sequencing with App-V on Windows 10 Enterprise

The holidays are almost over, but I have been busy with many little side projects. I've meant to produce some instructional videos for years, and I finally got around to making something. I've been teaching App-V since the SoftGrid days and maintain a set of courseware with fellow MVP Tim Mangan.

My first video is a simple overview of sequencing a simple application. In these 15 minutes, you should have enough information to get a quick primer as to how to sequence an application on using App-V 5.1 on Windows 10 build 1607.

I hope you find the video useful and I hope to produce some more. In my next video, I will cover running the sequenced application on a Windows 10 1607 client.

Using PowerShell to Get Office 365 ActiveSync Device Information

I had a situation where I needed to get some device information about what was connected to my customer's current Office365 ActiveSync environment. Luckily after searching the Internet, I found this process to be rather simple, and I thought I would put my solution up on my blog to give an example of how to do it.

The code I put together focuses around using the get-mobiledevice commandlet rather than the older and eventually slated to be decommissioned get-activesyncdevice commandlet. I also added the export-csv commandlet to give me some output I could easily load into excel. If I put some extra work into it, I could make a native export to Excel, but I was doing a quick and dirty dump of the data.

To kick things off, we need to connect to Office365 so the following code I copied intact from TechNet: https://technet.microsoft.com/library/jj984289(v=exchg.160).aspx
*Make sure to open the PowerShell ISE or shell as an administrator.


Set-ExecutionPolicy RemoteSigned

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session

You should be prompted with a login prompt to connect with your Office365 credentials at this point. The next line is where I pull out specific information about what is connected to ActiveSync.

get-mobiledevice | select deviceid,mobileoperator,id,deviceos,deviceimei,DeviceTelephoneNumber | export-csv C:\Activesync.csv

In the end, I make sure to disconnect my session if I decide to do further work with a different tenant.

Remove-PSSession $Session

I've added a link over here to the full script if you want to download and modify it to suit your needs.
https://1drv.ms/u/s!An-INXqoazfRkckHDEqeUc6lDxXyWw

Make sure to test out the get-mobiledevice commandlet as it can give you a wide range of device information such as:

OriginatingServer
IsValid
ObjectState
RunspaceId
FriendlyName
DeviceId
DeviceImei
DeviceMobileOperator
DeviceOS
DeviceOSLanguage
DeviceTelephoneNumber
DeviceType
DeviceUserAgent
DeviceModel
FirstSyncTime
UserDisplayName
DeviceAccessState
DeviceAccessStateReason
DeviceAccessControlRule
ClientVersion
ClientType
IsManaged
IsCompliant
IsDisabled
AdminDisplayName
ExchangeVersion
Name
DistinguishedName
Identity
Guid
ObjectCategory
ObjectClass
WhenChanged
WhenCreated
WhenChangedUTC
WhenCreatedUTC
OrganizationId
Id
OriginatingServer
IsValid
ObjectState

When Does Driver Injection Make Sense?

Over the years I've generally stayed with a specific piece of advice when performing driver injection when deploying Windows images using Microsoft Deployment Toolkit or System Center Configuration Manager. You start with the expanded driver files and import them while removing drivers that are not relevant to the platform you are deploying. Then you deploy the operating system with driver injection to see which drivers successfully install then remediate the remaining by installing them manually and using a tool such as Driver Magician to export the drivers for import into Configuration Manager. Or you might need to make silent installations of the OEM driver installers that get installed as packages via the task sequence after the Windows operating system has been applied.

All of these techniques generally works well with the exception of storage and network drivers because if Windows PE does not have network or more importantly storage drivers that work with your hardware you won't be able to image the machine. If you look deeper you might realize that there is even more that needs to be considered when deploying drivers with your Windows operating system. For example the most obvious issue is the front end software a driver might have to perform tasks such as further configuring the behavior of the device to updating the device software on a regular basis. For example some of my users using a high end display setup may want the advanced configuration control panel for their device that would not be offered if we did simple driver injection. A perfect example would be the NVIDIA control panel below.

Of course automatic updates might not be desireable in an enterprise but the advanced features may be something to consider. Off the top of my head I've seen the following types of devices use additional software to enhance the driver experience.

• Mouse / Pointer
• Keyboard 
• Display
• Printer / Scanner / Multifunction Printer
• Trusted Platform Module Chip
• Network Adapters
• Bluetooth
• Sound Devices

Further to that there are some installers that expose more information about the device via WMI and the driver installer creates the related classes. The reason this might be of importance is if you are using client management software such as System Center Configuration Manager to collect hardware inventory data of your deployed systems.

What I am trying to recommend is that you take a closer look at how you build your systems and determine if deploying the driver itself gives the user the experience they need and satisfies the system administrator's requirements rather than just injecting as much as possible. The network and storage drivers will need to be initially injected if Windows PE cannot communicate with the devices out of the box but where you go from there should be done with some care rather than following some hard and fast rules.

Azure RemoteApp & App-V: Cloud Service vs Resource Manager

I've been playing around with Azure RemoteApp and App-V in Azure to find a nice little limitation that I think is a huge design consideration. Lately I've been deploying my virtual machines with Azure Resource Manager because it is the future platform and it offers many features not available in the Azure Cloud Services model. The main attraction to me is network security groups where I can essentially configure a network level firewall for different systems in Azure. But more importantly is the Resource Manager Templates, these allow you to build environments in Azure that can be exported to templates so that they can be easily provisioned for development, test and production environments.

The issue I wish to discuss is about a limitation many of you may not be aware of unless you try to deploy RemoteApp and require connectivity to servers in Azure Resource Manager. The first limitation is that the Azure RemoteApp servers must reside on a different virtual network than the servers provisioned using Azure Resource Manager. There can be no sharing of VNet address space between models. The most interesting part is that these virtual networks do not communicate to each other by default which creates the most challenging piece of the problem.

In order to provide connectivity between virtual networks you will need to implement a VPN between virtual networks. This means your bandwidth between networks will be constrained to 100 megabits (basic and standard) to 200 megabits (high speed) depending of the gateway you are using inside of Azure.

If you are deploying App-V Management Servers in Azure and want the best performance I would recommend that you deploy those virtual machines using Cloud Services for the short term. You may also want to keep this in mind with the supporting application infrastructure because the gateway could get congested with that traffic as well.

Here are some links as to help you with configuring the VPN if you need to pursue this architecture.

Connecting classic VNets to new VNets

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-arm-asm-s2s/

About VPN gateways

https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-about-vpngateways/

How do I Force an Intune Policy Sync on Windows 10

When testing or trying to resolve an issue the default sync settings with Intune can be lacking. If the device is enrolled the initial behavior is every 3 minutes for 30 minutes, and then every 24 hours. If a policy or application is sent to the device Intune will try to notify the device within five minutes, otherwise the device should check in every 24 hours. To force the policy sync on a device open the Start menu and select Settings.

Select Accounts.

Select Work access then the organization you are subscribed to. At this point there should be additional buttons that appear below. Click the sync button to do a policy synchronization with Intune.

To get more information about the sync action you can click the Info button.

You can see if the last sync was successful, when the last sync was successful and the last attempted sync. The URL of the management server being used is also displayed.

Intune Entrollment Error: System policies prevent you from connecting to a work or school account.

I had some fun getting to the bottom of this error and I found some potential issues that can cause this error to pop up that might not be apparent. We had the Azure AD user account configured for Azure AD Join and the user was not over the limit of devices they could enroll (default 5). We wanted to enroll the device into Intune using the following procedure. First open the Settings menu from the Start menu.

 Select Accounts.

Then select Work access and notice the error under Enroll in to device management.

What we did run into is two items that were generating the error.

1. Don't perform Azure AD Join with the default administrator account.
2. To enroll in Intune make sure the user performing Azure AD Join on the device is a local administrator.

Also make sure the machine is not domain joined and when the user enrolls the device into Azure AD they do not become a local administrator unless they were one to begin with. If the proper conditions are met the device enrollment dialog should have a plus sign to begin the enrollment process.

You will be asked to supply your Azure AD logon ID then click Continue.

Put in your password then click Sign in.

If two factor authentication is set up the follow page will appear. Select Set it up now to continue.

In this example I set my country to Canada then configured the system to send me a text message to the phone number I have configured previously for two factor authentication. I will click Contact me to continue the verification process.

I will enter in the security code sent to my cell phone then click Verify.

Now that I am authenticated I can select Done to complete the process.

You should now see your enrollment details in the Settings menu.

Hope this helps your experience go

a little more smoothly.