... but taking in consideration the work I’ve done during the last years as network and ISA/TMG support engineer I personally recommend the use of forwarders instead of root hints.

When you have TMG/ISA doing requests against a DC this configuration is quite important for having good performance... I had quite some issues related with this.
... also based on DNS Best Practice Analyzer Microsoft also recommends the use of forwarders.

I personally recommend to use your ISP DNS servers as forwarders.
The main reason for you to use Forwarders is related with performance – the number of hops required to reach your ISP DNS server is much lower for sure than to access the root hints.
The reason for use root hints is reliability, however in my opinion - this is an old idea…: - most of the Server providers are now reliable and they don’t change their DNS server IPs without proper information. 10 Years ago this was not the case… DNS Server in ISP sometimes were quite problematic and many people suggested and preferred to use Root Hints.
We have also another reason to use forwarders … this reason is related with Firewall configuration, It’s easy to allow only DNS external traffic against those specific ISP DNS Server used has forwarders.
https://technet.microsoft.com/en-us/library/cc816653(WS.10).aspx
Some other forums / discussion topics.
https://social.technet.microsoft.com/Forums/windowsserver/en-US/f815e91c-d8e7-42d8-9b1a-42492022b9e4/dns-forwarders?forum=winserverDS
https://social.technet.microsoft.com/Forums/windowsserver/en-US/2f35cae2-341c-4bfe-9dac-724ddace6d51/dns-question-root-hints-vs-forwarders?forum=winserverNIS

Unable to activate DirectAccess UAG configuration - The adapter configured as external-facing is connected to a domain. This interface cannot be used with UAG DirectAccess.

July 02, 2012 21:53:10               Error                                                                             The adapter configured as external-facing is connected to a domain. This interface cannot be used with UAG DirectAccess.
July 02, 2012 21:53:10               Error                                                                             The UAG DirectAccess configuration cannot be activated.
July 02, 2012 21:53:10               Error                                                                             DirectAccess could not be activated.

CAUSE
 

How Domain Determination

In all cases, detection starts the same way that it does in Windows XP. If the Connection Specific DNS Name matches the “HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName” registry key then the machine will attempt to contact a Domain Controller via LDAP. If both these steps succeed, you will get the Domain profile. It is important to note that if the steps succeed, processing stops here. This allows you to roam across multiple access points in the same domain without having to stop and identify each of them individually.

If you restart the UAG you can see that connection from the External IP reach the Internal Domain Controllers.

If you restart the Network Location Awareness again after UAG / TMG fully started no more connections arrive with external IP.

During startup the connection occurs because when you restart UAG or TMG the NLASvc starts faster than the TMG Firewall Service.

During that period the connection from External IP to DC is not controlled and connection is allowed.

RESOLUTION:

Make sure that Network Location Awareness starts only after fwsrv. DependOnService registry key for NLASvc and add fwsrv.

From SCCM machine we were unable to use Remote control against the DA clients that connect via UAG.

SCENARIO:

 Lab done based on this.

TROUBLESHOOTING DONE:

Doing a network trace on the SCCM we were able to see that SCCM tries to connect to FIRST to port 135 and I also saw connection to port 445 when issuing the Remote Control command. However documentation states:

 https://technet.microsoft.com/en-us/library/bb694088.aspx

 Remote Control

In order to use the remote tools features of Configuration Manager 2007, you need to allow the following ports:

• TCP port 2701
• TCP port 2702
• TCP port 135

My tests shown TCP/135 and TCP/445 and only after those connections work we see: TCP2701/TCP2702

I believe that this documentation should also have 445 here, actually documentation refers to File and Print sharing....

"Windows Event Viewer, Windows Performance Monitor and Windows Diagnostics

Network traces shows that TCP 445 connections are tried from SCCM to remote DA client.

On the DA Client, there’s no point in doing any network trace because all the traffic goes via IPSec Tunnel established between DA Client and UAG.

There’s specific ways to get this data using netsh but I didn’t follow that.

My goal now was to have port TCP 445 / 135 from internal network to DA clients working. Fact was that:

- DC is able to connect to DAClient:

- (ICMP) Ping -> work.  

- (TCP 3389) mstsc -> works

- (TCP 445) Access to Share -> Fails from DC or SCCM or any other machine in internal network.

Lot's of configuration tried in the Windows Firewall of the machine without success.

Until something was found:

...by default the Remote IP Scope when you enable (SMB in) in your firewall we got:

It was very tricky to find that this was the cause for the problem.

Of course this is wrong - “Local Subnet” for DA Client cannot be our internal network.

Changing this to “Any IP Address” started to work in my lab.

On the Windows Firewall of the DA client. I’ve configured a Local GPO to allow File and Print Sharing: (You can also set this by a Domain Policy or in GPO UAG Client Access policy.)

We wanted to make sure that we could focus in a specific range. Security is important.

How do we know what range to use?

From a DA Client do a ping to an internal machine and check the reply.

1. 2002:WWXX:YYZZ:8000::/49 as the organizational prefix
2.  2002:WWXX:YYZZ:8000::/64 as the ISATAP prefix
3.  2002:WWXX:YYZZ:8001::/96 as the NAT64/DNS64 prefix
4.  2002:WWXX:YYZZ:8100::/56 as the IP-HTTPS prefix

Ping reply was: 

2002:2700:e9:8000… etc… this means ISATAP

So added this range on my DA Client firewall.

With customer environment the firewall was 3^rd party but the logic was the same.

From Da client we did a ping to internal network, we saw reply being ISATAP and we added the entry.

 Shares working

Remote control started to work in production environment

Hope this helps...

Win7 RDP6.1 10.10.11.88   (VPN Network 192.168.33.0-192.168.33.255)
|
10.10.11.252 (UAGhttpsTrunk.allinone.com)
UAG
10.10.10.252
|
----------------------------------10.10.10.0/24-----------------------
|
DC(10.10.10.12) ex2010all.allinone.com default gateway of the DC is the UAG. If you have other DefaultGateway the

First think to do is to configure the trunk, you need to have a certificate and the CRL for that certificate must be accessible.

1) Create the trunk

So on the UAG console we start by creating the trunk:

We go to HTTPS Connections -> RClick -> New Trunk - Portal Trunk

I gave the name: UAGHttpsTrunk.allinone.external

On the Authentication Server select the internal DC - ex2010all.allinone.com -> Next

Select a certificate.

Important: (About the certificate, public name and CRL)

The public name of the certificate must match the name of the External name you are going to access.

In my case the VPN connection and trunk are going to be accessed by using the name UAGhttpsTrunk.allinone.external

This certificate has the CRL link that can be accessed correctly. This causes problems if not well configured.

 Next - Endpoint Policies I left the Default

Next - Finish

Creating the VPN SSTP

On top we go to Admin go to Remote Network Access and then select SSL Network Tunneling(SSTP)

 Select the Trunk we have created UAGhttpsTrunk

 Next - on protocols select SSTP

Next - Address Assignment I've created a entry where Start Address is 192.168.33.0 end address is 192.168.33.255 (don't worry about the network 0 and mask address 255, UAG takes care of that).

 ACTIVATE

 Save / Activate

CLIENT CONFIGURATION

Control Panel\All Control Panel Items\Network and Sharing Center

Setup a new connection or network

Next- Create a new connection

Next- Use My Internet connection VPN

Next - Add the address of the trunk

Next - user name and password

VPN Connected

You were able to access the internal DNS on the DC 10.10.10.12 with success

This is working.

You get a specific event on eventvwr application log because of this:

Event Source: Microsoft Firewall
Event ID: 14090
Server publishing rule [HTTPS] that maps IP:443 TCP to
IP:443 for protocol [HTTPS Server] was unable to bind a socket for the server. The server publishing rule cannot be applied.

By doing in command line:

netstat -ano |findstr :443

you are going to get displayed:
0.0.0.0:443
[::]:443

System with PID 4 is the owner for these entries.

You should make sure that DA is configured specifically to an External IP not used by any TMG listener otherwise you are going to get the error.

How to do that?

https://www.isaserver.org/tutorials/Microsoft-Forefront-TMG-How-configure-Forefront-TMG-DirectAccess-Server.html

https://blogs.technet.com/b/isablog/archive/2009/09/23/forefront-tmg-and-windows-7-directaccess.aspx

 What was the problem we faced:

IP-HTTPS creates a listener that bounds port 443 to all interfaces. We need to make sure that IP-HTTPS uses a specific IP.

This is achieved by doing:

netsh http add iplisten ipaddress=<non-conflicting IP address>”

Q. Can I configure IP-HTTPS and Forefront TMG SSL publishing on the same machine?

A. Both IP-HTTPS and Forefront TMG SSL publishing use port 443 (HTTPS). In order to prevent a port conflict you need to make sure that IP-HTTPS is configured to listen to a different IP address than Forefront TMG.

This can be done by running the following command: “netsh http add iplisten ipaddress=<non-conflicting IP address>

==

If you want to remove the DA and have TMG publishing rules working as fast as possible:

make sure you have the console installed for DA.

Unconfigure DA.

Make sure listener for IP-HTTPS is deleted:

netsh http del sslcert 0.0.0.0:443

netsh http del sslcert [::]:443

When we specific a proxy on IE, the same information appears in the WLM. File -> Options -> Connection -> Advanced Settings

However for some reason we’ve noticed via a network trace that a specific component wlidsvc, right now, is ignoring this setting.

However I’ve confirmed that this is working fine if we configure in the IE the proxy for automatically detect settings.

Everything worked for me if we use winhttp proxy + proxy configured IE

In win7 and 2008 you can configure winhttp proxy by doing:

Right now this two workarounds worked for me. I hope this help you.

Best regards and best of luck.

Hello

To create a bootable ISO you need to have a boot sector file, for example "El Torito".

Sharing with you how I 'vecreated a bootable ISO / bootable CD 

You need to use TWO - 3rd party tools.

1st tool - to create the boot sector file from a existent physical bootable CD.
(You may use the .bin file I've created and it's available in attachment).
There are lots tools on the Internet (3rd party tools) that allows the extraction of the boot sector from an existent physical bootable CD.
You can create that Sector File using for example BBIE.
There are many other tools that create the boot sector in many different formats.
I've extracted to a .bin file format.

2nd tool - You need to use another tool to create the ISO.
The tool must be able to add a boot sector file into the ISO.
During the ISO creation you have to specify the option to add the boot sector file.
There are lots of tools that do that.
The tool I used was the (cdimage). This tools requires the boot file in the .bin format.

 c:\CDIMAGE\cdimage.exe  -bF:\BootSectorFile\BootSectorElTorito.bin WinXPSp3Files XPSP3iso.iso

You may use Virtual PC 2007 attach the media to this ISO and check if the ISO is really bootable. (It should be!) 

Then you can use this ISO to burn a CD. The CD is going to be bootable.

I hope this helps.

Best regards,

BootSectorElTorito.zip

Hello,   I'm writing this post to provide you with the basic information and an example in how to create a ISA Filter to replace the Pragma:  no-cache - or Cache-Control:  no-cache sent by client(IE, ActiveX etc...).   This filter was created by following the Example provided by David Treadwell on July 1997.   https://www.microsoft.com/downloads/details.aspx?familyid=16682c4f-7645-4279-97e4-9a0c73c5162e&displaylang=en \Microsoft ISA 2006 SDK\samples\WebFilters\webresponsemodifier   I'm doing further testing regarding this filter, but this is a very good and simple startup. However to develop or alter this filter you need some development skills.   I suggest you to read all the information available at: https://msdn.microsoft.com/en-us/library/ms828061.aspx   The entry functions for the Filter are:   https://msdn.microsoft.com/en-us/library/ms812622.aspx •               GetFilterVersion •               HttpFilterProc   This means that for each http packet reaching ISA, the filter is called. The functions that are called are:GetFilterVersion and HttpFilterProc. You need to be careful with what you write because you can stop Microsoft Firewall very easy. This development should be made in lab environment and fully tested. During the development I got the following errors caused by incorrect code.   Event Type:            Error Event Source:        Microsoft ISA Server 2006 Event ID: 1000 Description: Faulting application wspsrv.exe, version 5.0.5723.493, stamp 48623ea3, faulting module unknown, version 0.0.0.0, stamp 00000000, debug? 0, fault address 0x110e3b8e.   Event Type:            Error Event Source:        Microsoft ISA Server Control Event ID: 14079 Description: Due to an unexpected error, the service fwsrv stopped responding to all requests. Stop the service or the corresponding process if it does not respond, and then start it again. Check for related error messages.   What does this example exactly does? -> For all the request made to ISA and that reached the filter, We check if the website we are accessing is www.ola.com. if it's www.ola.com I change the Pragma:  no-cache - and Cache-Control:  no-cache to Pragma:  none - and Cache-Control:  none. So this will be ignored by ISA and the information will be cached. -> All the debug information is being sent to the Debugger. So I suggest you to use DebugView from Sysinternals for troubleshooting purposes. The function used to send the data to the debugger is: OutputDebugStringA(LPCWSTR)   Lets go back to the main entry function:   DWORD WINAPI HttpFilterProc (     PHTTP_FILTER_CONTEXT pfc,     DWORD NotificationType,__inout     LPVOID pvNotification)     The entry function HttpFilterProc has 3 arguments: PHTTP_FILTER_CONTEXT pfc Pointer to an HTTP_FILTER_CONTEXT structure that is associated with the current, active HTTP transaction "The HTTP_FILTER_CONTEXT structure is used for passing control and information associated with the current, active HTTP session in event notifications that are sent by the ISA Server Web proxy to Web filters by calling HttpFilterProc and HttpWPXFilterProc." https://msdn.microsoft.com/en-us/library/ms826756.aspx   DWORD NotificationType Pointer to a bitmask that indicates the type of notification event that is being processed. The NotificationType argument, this argument tells you in what situation the function was called. I wanted to change the header when the information reached ISA for the first time so I believe that this happens when the NotificationType is SF_NOTIFY_PREPROC_HEADERS. https://msdn.microsoft.com/en-us/library/ms812625.aspx   LPVOID pvNotification Pointer to a notification-specific structure that contains additional information about the current context of the request. The following table shows the possible notification types and the corresponding structures. So when you get this notification type the argument pvNotification that is a Void is used to create a catch to the structure of the type: HTTP_FILTER_PREPROC_HEADERS   HTTP_FILTER_PREPROC_HEADERS * pPPH; pPPH = (HTTP_FILTER_PREPROC_HEADERS*)pvNotification; Important: Each notification may need a specific  catch to be used.   In my code I've: DWORD WINAPI HttpFilterProc (     PHTTP_FILTER_CONTEXT pfc,     DWORD NotificationType,__inout     LPVOID pvNotification ) {   pfc->GetServerVariable(pfc,(LPSTR)String_HTTP_HOST,HTTP_HOST,&HTTP_HOST_LEN); --> This is used to get the HTTP_HOST. if(NotificationType == SF_NOTIFY_PREPROC_HEADERS && strcmp(HTTP_HOST,"www.ola.com")==0) {                 -->We will only enter if the HTTP_HOST is www.ola.com and only when the notificationType is SF_NOTIFY_PREPROC_HEADERS.                   --> We then do a catch from the pvNotification to the correct Structure HTTP_FILTER_PREPROC_HEADERS.                 --> These structure included a pointer to the SetHeader function and we can use it.   HTTP_FILTER_PREPROC_HEADERS * pPPH;                                                   BOOL fResult;                                                                   pPPH = (HTTP_FILTER_PREPROC_HEADERS*)pvNotification;                                                                                                                 fResult = pPPH->SetHeader( pfc,  "Cache-Control:",  "None" );                                                   fResult = pPPH->SetHeader( pfc,  "Pragma:",  "None" );                                                   }   One more note if you compile the code provided in the SDK you will get Firewall stopped in the first HTTP access with error: 0x80070057 BOOL WINAPI GetFilterVersion ( PHTTP_FILTER_VERSION pVer ) { ……………………… ……………………… ……………………… pVer->dwFilterVersion = MAKELONG(0,6);} I hope this helps.   Best regards to all.

Mywebresponsemodifier.rar