Test Application for Group Policy Software Installation Troubleshooting

Sometimes when diagnosing problems with Group Policy software deployment, it is good to try a different application to rule out issues with the application package your trying to deploy.  One application package I have found which is great for testing Group Policy software deployment is "RealWorld Paint".  This is a lightweight MSI installer (8.7 MB) in size and deploys easy through Group Policy to Windows XP, Windows 7 and Windows 8.1 machines.

You can download this MSI installer from the following location:

http://download.rw-designer.com/2013.1/RWPaint32.msi

If you have issues deploying this with Group Policy, then the issue does not lay with the MSI package your trying to deploy but something else!

Also check out this common issue with Group Policy application deployment, it may be of help in diagnosing your Group Policy deployment issue:

http://clintboessen.blogspot.com.au/2013/01/group-policy-software-installation-not.html

HyperV Network Types

Microsoft HyperV servers have three Network Types you can assign to Virtual Machines and Virtual Switches.

• Private
• Internal
• External

This is shown below on both a virtual machine and a virtual switch configuration.

 

 

What is the difference between these?

 

An External Network Type provides communication between a virtual machine and a physical network by creating an association with a physical network adapter on the virtualization server.  This is the most common type used by organisations.

 

An Internal Network provides communication between the virtualization server and the virtual machines.

 

A Private Network only provides communication between the virtual machines and not the HyperV host server.

 

Internal and Private network types can be confusing - the only difference is Internal also allows the virtual machines to communicate with the HyperV host server.

GFI MailEssentials 2014 SR2 Transport Issues during Exchange Migration

I had an issue with a third party email filtering product GFI MailEssentials 2014 SR2 during an Exchange 2010 to Exchange 2013 migration.  GFI MailEssentials 2014 SR2 is a spam filtering product which you install directly on an Exchange transport server.  It integrates with Exchange server through six transport agents which all perform various tasks as shown below:

 

When migrating to a new version of Exchange, as part of the process you are required to redirect mail flow to the new Exchange transport server so it can route the mail to the legacy transport environment until a point when the mailboxes can be moved.

 

As the new Exchange 2013 server will be the new external point of connectivity for SMTP, I installed GFI Mail Essentials on the new Exchange 2013 server and redirected mail flow as shown below.

 

 

After making this change, users were not able to receive email from external users.  I verified the following things:

• Exchange 2013 was receiving emails from external users as validated in the SMTP Protocol logs.
• Exchange 2013 was forwarding emails to the Exchange 2010 server as per standard functionality.
• Exchange 2010 successfully received the email communication from Exchange 2013 at transport level and was verified in the protocol logs.
• GFI MailEssentials Transport Agents on the Exchange 2010 server receive the email for processing.
• GFI MailEssentials does not place the email back into the Exchange Pickup folder giving it back to Exchange for processing.

I was not able to locate where the emails were moved to within GFI primarily due to my limited knowledge of the product (to me it is just a custom Exchange transport agent).  I contacted GFI support here in Australia who were also unable to advise me where the emails went after being relayed to the Exchange 2010 server.  Fantastic, so we have emails going into a black hole disappearing forever.

 

One thing GFI support were able to advise me was their transport agents only filter email which was sent from a public IP address, all private IP addresses were excluded from filtering.  This was in line with my symptoms, all users internally were able to receive emails sent from internal devices such as Printers being relayed through the Exchange 2013 server.

 

In the following screenshot I have included the message tracking log from the Exchange 2010 server.  The first two entries are from when the Cisco Router was forwarding email directly at the Exchange 2010 server.  All other entries are from when mail was relaying through Exchange 2013.  As you see email is received via SMTP however not delivered to the information store via the Exchange Store Driver due to GFI not releasing the mail.

 

 

GFI Mail Essentials modifies the header of emails that are filtered and appears to not deal with emails correctly which already have their header modified by another instance of GFI Mail Essentials.

 

As a work around I simply disabled the GFI Transport Agents on the Exchange 2010 server to prevent it from interfering with mail processing to resolve the issue as shown below:

 

 

This resolved the issue and did not compromise the environment as security and spam filtering was now being performed by GFI on the Exchange 2013 server.

Microsoft Exchange Virus Scanning API (VSAPI) Removed

Back at the MVP Summit 2012 in Redmond, Microsoft announced to the Exchange MVP community that in Exchange 2013 they are going to pull the Microsoft Exchange Virus Scanning API (VSAPI) from the product.  This API is what allows anti-virus products to scan inside the information store for emails.  This early news came to me with a big smile on my face!

For years I have been advising customers NOT to install anti-virus products which scan the information store as it causes unnecessary load on the information store and has caused database corruption at some of my customers.  Despite my advice, some of my clients go ahead and installed this functionality anyway to meet a "compliance" checkbox which some integrator has flagged in a security audit.

I have always advised customers to perform anti-virus scanning at a transport level (SMTP) and flag emails before they reach the database to improve performance and allow for greater scalability.  It is important to note however, Anti-Virus products are always releasing new definitions and it is possible that a virus was allowed in due to the definitions not being able to detect it initially but being able to detect it at a later date.  Hence, this still proposes a risk to the business and can be caught using third party Anti-Virus products which use the Microsoft Exchange Virus Scanning API (VSAPI) right?  Well yes this is true, however I still do not recommend this.  A better solution is to run cached Exchange mode and allow client side Anti-Virus products to scan the users offline cache "OST file" for viruses on a regular basis and offset this load from your already busy mail servers.  This approach meets the same objective and does not require use of the Microsoft Exchange Virus Scanning API.

One of my customers who went against my advise and refused to disable Information Store scanning due to compliance requirements on Exchange 2010 now has no option but to remove it.   Microsoft Support must have finally had enough of dealing with issues from third party Anti-Virus products causing information store issues just like me!

Have a look at the following screenshot comparing a product GFI MailEssentials 2014 SR2 which has the ability to scan the information store on a Exchange 2010 server compared to an Exchange 2013 server.  Under the Email Security menu on the Exchange 2013 server (on the right), you will se the feature gone for good... not just in GFI but all anti-virus products.

A big thankyou to Microsoft for removing this API - this is one less argument I need to have with my customers!

Lastly, I still always recommend companies AppLock with Microsot AppLocker in Enterprise edition of Windows and do away with definition scanning Anti-Virus solutions, they are a thing of the past.  This is another argument I'm still having with the security compliance guys stuck in the dark ages, but we will save this for another blog post.

RemoteApp Disconnected This computer can't connect to the remote computer

After deploying a Remote Desktop Services environment on Server 2012 R2, users complained of an issue where they were no longer able to launch RemoteApps from the RD Web App portal.  The error they received was:

RemoteApp Disconnected

This computer can't connect to the remote computer.

Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

To resolve this issue open the properties for your application collection experiencing problems, navigate to security and untick "Allow connections only from computers running Remote Desktop with Network Level Authentication".

 

This sorted out the problem in my environment.