Fortigate SSL VPN Client cannot resolve FQDNs

Recently had a customer complain that he cannot access documents on his file server when connected via SSL VPN. Closer inspection showed that the customer was trying to access the fileserver by hostname “\\fileserver” as opposed to “\\fileserver.corp.local”.

The fix seemed to be simple, implement a DNS search suffix. Unfortunately there is no such option in the GUI, so I had to set it via command-line.

Set DNS search suffix using CLI

config vpn ssl settings
set dns-suffix corp.local
end

Set Client DNS Server in the GUI

Navigate to VPN –> SSL –> Settings –> Tunnel Mode Client Settings.  Specify the DNS Server setting and enter the IP addresses of your corporate DNS servers.

Your Fortigate will now append the “corp.local” suffix to all non-qualified hostnames.  This was tested on FortiOS 5.06, 5.07 and 5.2

SCCM 2012 R2 Collection Queries

After spending a considerable amount outside of the Microsoft ecosystem I recently found myself running a project where I had to deploy SCCM 2012 R2 for a customer.  I immediately caught myself wishing I made notes of my basic collection queries during my prior deployments.  Consequently I decided to document them in one place now:-)

All Dell Systems

select
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceID where SMS_G_System_COMPUTER_SYSTEM.Manufacturer like "Dell%"

All Server Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SYSTEM.SystemRole = "Server"

All Workstations

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SYSTEM.SystemRole = "Workstation"

All Domain Controllers

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.PrimaryGroupID = "516"

Removing persistent proxy settings

This is one of those things that I find I constantly have to google.  Oftentimes app traffic will just not flow correctly, more often than not the issue is with an outdated proxy setting.  What trips one up here is the fact that this proxy is not listed in your IE proxy settings.  The issue is that the winhttp proxy component has been set – below is how we can manipulate it.

View Current Proxy Settings

• Windows Vista / 7 / 8 command line: netsh winhttp show proxy
• Windows XP command line: proxycfg

Reset Proxy Settings

• Windows Vista / 7 / 8 command line: netsh winhttp reset proxy
• Windows XP command line: proxycfg /d

Simple fix to a potentially frustrating problem!