DirectAccess serveri paigaldamine ja haldamine Windows Server operatsioonisüsteemis - Revision history

Akulikov at 19:50, 1 April 2011

2011-04-01T19:50:35Z

← Older revision		Revision as of 22:50, 1 April 2011
Line 4:		Line 4:

	DirectAccess tekitab [[IPSec]] tunneli kliendilt DirectAccess serverisse ja kasutab IPv6 protokolli, et jõuda DirectAccess serverisse või teiste DirectAccess klientideni. See tehnoloogia kasutab IPv6 traffikut läbi IPv4 võrgu, et jõuda sisevõrku läbi interneti, mis endiselt baseerub IPv4 protokollil.		DirectAccess tekitab [[IPSec]] tunneli kliendilt DirectAccess serverisse ja kasutab IPv6 protokolli, et jõuda DirectAccess serverisse või teiste DirectAccess klientideni. See tehnoloogia kasutab IPv6 traffikut läbi IPv4 võrgu, et jõuda sisevõrku läbi interneti, mis endiselt baseerub IPv4 protokollil.

			[[File:da9.png]]

	==Nõudmised==		==Nõudmised==

Akulikov: /* Konfigureerimise viisard: Klient */

2011-04-01T19:48:23Z

Konfigureerimise viisard: Klient

← Older revision		Revision as of 22:48, 1 April 2011
Line 28:		Line 28:
	==DirectAccess haldamine==		==DirectAccess haldamine==

	=== Konfigureerimise viisard: ~~Klient~~ ===		=== Konfigureerimise viisard: Client ===

	~~Esimene seadistamise viisard on päris otsene ja esitab Teile ainult ühe küsimuse~~: ~~Mis arvutite gruppid Teie soovite lubada~~ DirectAccess ~~kasutamiseks~~.		The first Wizard in configuring DirectAccess is pretty straight forward and asks only one question: What groups of computers do you want to enable for DirectAccess?

			I find it most useful to create one active directory security group called “DirectAccess Enabled Computers” that can be used for actually enabling DirectAccess. You can then add Computers or even other Groups of Computers as members of this group. This allows you to manage who has DirectAccess from within Active Directory and you won’t need to revisit this wizard or modify Group Policy later. You should note that once you add a computer to this group they will need to process group policy in order to become DirectAccess enabled. This means they will need to be connected to the domain for the first time in order to come online.

			To get started click the Edit button in the Clients group.

			[[File:da7.png]]

	~~Kõige kindlam on luua Active Directory turvagruppi nimega "~~DirectAccess ~~Enabled~~ computers~~", mida saab viisardis valida ja lisada gruppi hulka, millel on lubatud DirectAccessi kasutamine~~. ~~See aitab säästa aja, kuna siis saab gruppi redigeerida vastavalt vajadustele otse Active Directory alt ja siis ei pea uuesti avama viisardi, et muuta gruppe või kasutajaid~~.		Now click the Add button and select the AD Security Group that you want to use to enable DirectAccess for it’s member computers.

			[[File:da8.png]]

	~~Et alustada vajutage Edit nuppu Client Group valiku all~~.		You can enter several groups here but I like to enter just the one “DirectAccess Enabled Computers” and then mange membership of that group from Active Directory.

	~~Nüüd vajutage Add nuppu ja valike AD turvagruppi, mida Teie soovite lubada~~ DirectAccess ~~kasutamiseks~~.		Click finish and you’re done! Keep in mind that if you already have a configuration in place then changing this setting will not automatically enable a new group for DirectAccess. The configuration will need to be Generated AND Activated, then the client computers will also need to fetch the new policy, as is the case with any other changes to the UAG configuration. If this is the first time you’re running through this configuration don’t worry about activating the configuration just yet. You have pleanty more to run through first.

	~~Teie saate panna mitu gruppi siia~~, ~~aga mugavam on lisada ühe gruppi ja siis hiljem juba muuta arvutite nimekirja otse Active Directory alt~~.

	~~Vajutage Finish nuppu ja sellega algne seadistus saab tehtud~~.

	=== Konfigureerimise viisard: DirectAccess server ===		=== Konfigureerimise viisard: DirectAccess server ===

Akulikov: /* Konfigureerimise viisard: DirectAccess server */

2011-04-01T19:46:44Z

Konfigureerimise viisard: DirectAccess server

← Older revision		Revision as of 22:46, 1 April 2011
Line 48:		Line 48:
	NOTE: At the time of this writting, Forefront UAG Update 1 and earlier has a known bug in this particular wizard that can appear when you reach the page about selecting certificates. Microsoft delevopers are aware of the issue as discussed here in the Microsoft Forefront forum but I have been told that there won’t be a fix until UAG Service Pack 1 due for release around the end of 2010. It seems to be fine the first time you go through the wizard but if you select one certificate type and then rerun the wizard and select the other type the wizard will peg the CPU at 100% on the third and any subsequent times that you run the wizard. So the moral of the story here is to get it right the first time and you’ll be fine. Otherwise you may need to wipe the entire UAG Configuration (by running configmgrutil -del) and start all over.		NOTE: At the time of this writting, Forefront UAG Update 1 and earlier has a known bug in this particular wizard that can appear when you reach the page about selecting certificates. Microsoft delevopers are aware of the issue as discussed here in the Microsoft Forefront forum but I have been told that there won’t be a fix until UAG Service Pack 1 due for release around the end of 2010. It seems to be fine the first time you go through the wizard but if you select one certificate type and then rerun the wizard and select the other type the wizard will peg the CPU at 100% on the third and any subsequent times that you run the wizard. So the moral of the story here is to get it right the first time and you’ll be fine. Otherwise you may need to wipe the entire UAG Configuration (by running configmgrutil -del) and start all over.

	[[File:da1.~~jpg~~]]		[[File:da1.png]]

	Remember, I am assuming that your internal network infrastructure is running purely IPv4. With that in mind, the first page of this wizard will sort of tell you if you have things set up right…but you have to know what you are looking for. If you notice that the dropdown list for IPv4 is disabled, then you’re missing something. It looks like this:		Remember, I am assuming that your internal network infrastructure is running purely IPv4. With that in mind, the first page of this wizard will sort of tell you if you have things set up right…but you have to know what you are looking for. If you notice that the dropdown list for IPv4 is disabled, then you’re missing something. It looks like this:

	[[File:da2.~~jpg~~]]		[[File:da2.png]]

	This usually means the wizard was unable to find an ISATAP router and assumes you are using IPv6 on your internal network becuase, well, without ISATAP to convert IPv6 into IPv4 you would need native IPv6 for DirectAccess to work. Since we do not have IPv6 internally and we want to use ISATAP, there are two things to check in order to correct this:		This usually means the wizard was unable to find an ISATAP router and assumes you are using IPv6 on your internal network becuase, well, without ISATAP to convert IPv6 into IPv4 you would need native IPv6 for DirectAccess to work. Since we do not have IPv6 internally and we want to use ISATAP, there are two things to check in order to correct this:
Line 60:		Line 60:
	Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.		Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.

	[[File:da3.~~jpg~~]]		[[File:da3.png]]

	The two dropdown lists should be populated with only one option in each. In the left DDL for the Internet-facing IPv4 address select the first public IP on your server and then you should see the second address appear underneath the drop-down. In the right DDL for the Internal IPv4 address select the server’s intranet address and then the wizard should tell you that it will be enabling ISATAP and that you should create the DNS record for ISATAP. Of course that’s a little ironic being that you needed to do that beforehand.		The two dropdown lists should be populated with only one option in each. In the left DDL for the Internet-facing IPv4 address select the first public IP on your server and then you should see the second address appear underneath the drop-down. In the right DDL for the Internal IPv4 address select the server’s intranet address and then the wizard should tell you that it will be enabling ISATAP and that you should create the DNS record for ISATAP. Of course that’s a little ironic being that you needed to do that beforehand.

	[[File:da4.~~jpg~~]]		[[File:da4.png]]

	Next leave both NAT64 and DNS64 checked. If you don’t you will either need to configure your own services or be unable to connect to IPv4 targets. So, yeah, leave those checked.		Next leave both NAT64 and DNS64 checked. If you don’t you will either need to configure your own services or be unable to connect to IPv4 targets. So, yeah, leave those checked.

	[[File:da5.~~jpg~~]]		[[File:da5.png]]

	Finally, you need to select the select the certificate for the server that is issuing the certs to your enterprise. At this point you should have already generated a web certificate to be used for IP-HTTPS and imported it into the Computer account’s Personal Certificates store of the UAG server. Select both certificates and click Finish.		Finally, you need to select the select the certificate for the server that is issuing the certs to your enterprise. At this point you should have already generated a web certificate to be used for IP-HTTPS and imported it into the Computer account’s Personal Certificates store of the UAG server. Select both certificates and click Finish.

	[[File:da6.~~jpg~~]]		[[File:da6.png]]

	It may be appropriate to point out here that IP-HTTPS, while it is the least desierable connection method due to it’s overhead, it is incredibly useful since it is the option most likely to work in “unusual” scenarios due to popular support for connecting to secure web sites through firewalls. When it comes to the configuration of the UAG server, it does proxy all IP-HTTPS trafic through a local instance of IIS. To accomplish this the UAG Wizard seems to wipe and re-write the IIS settings when activating the UAG configuration. Why is that important? Well, you should not expect to be able to use the IIS installation on the UAG server for anything other than IP-HTTPS. So don’t bother adding another site or try to bind one to a different IP or even make some subdirectories in any existing site. UAG will destroy it and it doesn’t tell you about it either.		It may be appropriate to point out here that IP-HTTPS, while it is the least desierable connection method due to it’s overhead, it is incredibly useful since it is the option most likely to work in “unusual” scenarios due to popular support for connecting to secure web sites through firewalls. When it comes to the configuration of the UAG server, it does proxy all IP-HTTPS trafic through a local instance of IIS. To accomplish this the UAG Wizard seems to wipe and re-write the IIS settings when activating the UAG configuration. Why is that important? Well, you should not expect to be able to use the IIS installation on the UAG server for anything other than IP-HTTPS. So don’t bother adding another site or try to bind one to a different IP or even make some subdirectories in any existing site. UAG will destroy it and it doesn’t tell you about it either.

Akulikov: /* Konfigureerimise viisard: DirectAccess server */

2011-04-01T19:45:29Z

Konfigureerimise viisard: DirectAccess server

← Older revision		Revision as of 22:45, 1 April 2011
Line 48:		Line 48:
	NOTE: At the time of this writting, Forefront UAG Update 1 and earlier has a known bug in this particular wizard that can appear when you reach the page about selecting certificates. Microsoft delevopers are aware of the issue as discussed here in the Microsoft Forefront forum but I have been told that there won’t be a fix until UAG Service Pack 1 due for release around the end of 2010. It seems to be fine the first time you go through the wizard but if you select one certificate type and then rerun the wizard and select the other type the wizard will peg the CPU at 100% on the third and any subsequent times that you run the wizard. So the moral of the story here is to get it right the first time and you’ll be fine. Otherwise you may need to wipe the entire UAG Configuration (by running configmgrutil -del) and start all over.		NOTE: At the time of this writting, Forefront UAG Update 1 and earlier has a known bug in this particular wizard that can appear when you reach the page about selecting certificates. Microsoft delevopers are aware of the issue as discussed here in the Microsoft Forefront forum but I have been told that there won’t be a fix until UAG Service Pack 1 due for release around the end of 2010. It seems to be fine the first time you go through the wizard but if you select one certificate type and then rerun the wizard and select the other type the wizard will peg the CPU at 100% on the third and any subsequent times that you run the wizard. So the moral of the story here is to get it right the first time and you’ll be fine. Otherwise you may need to wipe the entire UAG Configuration (by running configmgrutil -del) and start all over.

	[[File:~~Example~~.jpg]]		[[File:da1.jpg]]

	Remember, I am assuming that your internal network infrastructure is running purely IPv4. With that in mind, the first page of this wizard will sort of tell you if you have things set up right…but you have to know what you are looking for. If you notice that the dropdown list for IPv4 is disabled, then you’re missing something. It looks like this:		Remember, I am assuming that your internal network infrastructure is running purely IPv4. With that in mind, the first page of this wizard will sort of tell you if you have things set up right…but you have to know what you are looking for. If you notice that the dropdown list for IPv4 is disabled, then you’re missing something. It looks like this:

	[[File:~~Example~~.jpg]]		[[File:da2.jpg]]

	This usually means the wizard was unable to find an ISATAP router and assumes you are using IPv6 on your internal network becuase, well, without ISATAP to convert IPv6 into IPv4 you would need native IPv6 for DirectAccess to work. Since we do not have IPv6 internally and we want to use ISATAP, there are two things to check in order to correct this:		This usually means the wizard was unable to find an ISATAP router and assumes you are using IPv6 on your internal network becuase, well, without ISATAP to convert IPv6 into IPv4 you would need native IPv6 for DirectAccess to work. Since we do not have IPv6 internally and we want to use ISATAP, there are two things to check in order to correct this:
Line 60:		Line 60:
	Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.		Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.

	[[File:~~Example~~.jpg]]		[[File:da3.jpg]]

	The two dropdown lists should be populated with only one option in each. In the left DDL for the Internet-facing IPv4 address select the first public IP on your server and then you should see the second address appear underneath the drop-down. In the right DDL for the Internal IPv4 address select the server’s intranet address and then the wizard should tell you that it will be enabling ISATAP and that you should create the DNS record for ISATAP. Of course that’s a little ironic being that you needed to do that beforehand.		The two dropdown lists should be populated with only one option in each. In the left DDL for the Internet-facing IPv4 address select the first public IP on your server and then you should see the second address appear underneath the drop-down. In the right DDL for the Internal IPv4 address select the server’s intranet address and then the wizard should tell you that it will be enabling ISATAP and that you should create the DNS record for ISATAP. Of course that’s a little ironic being that you needed to do that beforehand.

	[[File:~~Example~~.jpg]]		[[File:da4.jpg]]

	Next leave both NAT64 and DNS64 checked. If you don’t you will either need to configure your own services or be unable to connect to IPv4 targets. So, yeah, leave those checked.		Next leave both NAT64 and DNS64 checked. If you don’t you will either need to configure your own services or be unable to connect to IPv4 targets. So, yeah, leave those checked.

	[[File:~~Example~~.jpg]]		[[File:da5.jpg]]

	Finally, you need to select the select the certificate for the server that is issuing the certs to your enterprise. At this point you should have already generated a web certificate to be used for IP-HTTPS and imported it into the Computer account’s Personal Certificates store of the UAG server. Select both certificates and click Finish.		Finally, you need to select the select the certificate for the server that is issuing the certs to your enterprise. At this point you should have already generated a web certificate to be used for IP-HTTPS and imported it into the Computer account’s Personal Certificates store of the UAG server. Select both certificates and click Finish.

	[[File:~~Example~~.jpg]]		[[File:da6.jpg]]

	It may be appropriate to point out here that IP-HTTPS, while it is the least desierable connection method due to it’s overhead, it is incredibly useful since it is the option most likely to work in “unusual” scenarios due to popular support for connecting to secure web sites through firewalls. When it comes to the configuration of the UAG server, it does proxy all IP-HTTPS trafic through a local instance of IIS. To accomplish this the UAG Wizard seems to wipe and re-write the IIS settings when activating the UAG configuration. Why is that important? Well, you should not expect to be able to use the IIS installation on the UAG server for anything other than IP-HTTPS. So don’t bother adding another site or try to bind one to a different IP or even make some subdirectories in any existing site. UAG will destroy it and it doesn’t tell you about it either.		It may be appropriate to point out here that IP-HTTPS, while it is the least desierable connection method due to it’s overhead, it is incredibly useful since it is the option most likely to work in “unusual” scenarios due to popular support for connecting to secure web sites through firewalls. When it comes to the configuration of the UAG server, it does proxy all IP-HTTPS trafic through a local instance of IIS. To accomplish this the UAG Wizard seems to wipe and re-write the IIS settings when activating the UAG configuration. Why is that important? Well, you should not expect to be able to use the IIS installation on the UAG server for anything other than IP-HTTPS. So don’t bother adding another site or try to bind one to a different IP or even make some subdirectories in any existing site. UAG will destroy it and it doesn’t tell you about it either.

Akulikov: /* Konfigureerimise viisard: DirectAccess server */

2011-04-01T19:44:17Z

Konfigureerimise viisard: DirectAccess server

← Older revision		Revision as of 22:44, 1 April 2011
Line 48:		Line 48:
	NOTE: At the time of this writting, Forefront UAG Update 1 and earlier has a known bug in this particular wizard that can appear when you reach the page about selecting certificates. Microsoft delevopers are aware of the issue as discussed here in the Microsoft Forefront forum but I have been told that there won’t be a fix until UAG Service Pack 1 due for release around the end of 2010. It seems to be fine the first time you go through the wizard but if you select one certificate type and then rerun the wizard and select the other type the wizard will peg the CPU at 100% on the third and any subsequent times that you run the wizard. So the moral of the story here is to get it right the first time and you’ll be fine. Otherwise you may need to wipe the entire UAG Configuration (by running configmgrutil -del) and start all over.		NOTE: At the time of this writting, Forefront UAG Update 1 and earlier has a known bug in this particular wizard that can appear when you reach the page about selecting certificates. Microsoft delevopers are aware of the issue as discussed here in the Microsoft Forefront forum but I have been told that there won’t be a fix until UAG Service Pack 1 due for release around the end of 2010. It seems to be fine the first time you go through the wizard but if you select one certificate type and then rerun the wizard and select the other type the wizard will peg the CPU at 100% on the third and any subsequent times that you run the wizard. So the moral of the story here is to get it right the first time and you’ll be fine. Otherwise you may need to wipe the entire UAG Configuration (by running configmgrutil -del) and start all over.

			[[File:Example.jpg]]

	Remember, I am assuming that your internal network infrastructure is running purely IPv4. With that in mind, the first page of this wizard will sort of tell you if you have things set up right…but you have to know what you are looking for. If you notice that the dropdown list for IPv4 is disabled, then you’re missing something. It looks like this:		Remember, I am assuming that your internal network infrastructure is running purely IPv4. With that in mind, the first page of this wizard will sort of tell you if you have things set up right…but you have to know what you are looking for. If you notice that the dropdown list for IPv4 is disabled, then you’re missing something. It looks like this:

			[[File:Example.jpg]]

	This usually means the wizard was unable to find an ISATAP router and assumes you are using IPv6 on your internal network becuase, well, without ISATAP to convert IPv6 into IPv4 you would need native IPv6 for DirectAccess to work. Since we do not have IPv6 internally and we want to use ISATAP, there are two things to check in order to correct this:		This usually means the wizard was unable to find an ISATAP router and assumes you are using IPv6 on your internal network becuase, well, without ISATAP to convert IPv6 into IPv4 you would need native IPv6 for DirectAccess to work. Since we do not have IPv6 internally and we want to use ISATAP, there are two things to check in order to correct this:
Line 60:		Line 60:
	Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.		Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.

			[[File:Example.jpg]]

	The two dropdown lists should be populated with only one option in each. In the left DDL for the Internet-facing IPv4 address select the first public IP on your server and then you should see the second address appear underneath the drop-down. In the right DDL for the Internal IPv4 address select the server’s intranet address and then the wizard should tell you that it will be enabling ISATAP and that you should create the DNS record for ISATAP. Of course that’s a little ironic being that you needed to do that beforehand.		The two dropdown lists should be populated with only one option in each. In the left DDL for the Internet-facing IPv4 address select the first public IP on your server and then you should see the second address appear underneath the drop-down. In the right DDL for the Internal IPv4 address select the server’s intranet address and then the wizard should tell you that it will be enabling ISATAP and that you should create the DNS record for ISATAP. Of course that’s a little ironic being that you needed to do that beforehand.

			[[File:Example.jpg]]

	Next leave both NAT64 and DNS64 checked. If you don’t you will either need to configure your own services or be unable to connect to IPv4 targets. So, yeah, leave those checked.		Next leave both NAT64 and DNS64 checked. If you don’t you will either need to configure your own services or be unable to connect to IPv4 targets. So, yeah, leave those checked.

			[[File:Example.jpg]]

	Finally, you need to select the select the certificate for the server that is issuing the certs to your enterprise. At this point you should have already generated a web certificate to be used for IP-HTTPS and imported it into the Computer account’s Personal Certificates store of the UAG server. Select both certificates and click Finish.		Finally, you need to select the select the certificate for the server that is issuing the certs to your enterprise. At this point you should have already generated a web certificate to be used for IP-HTTPS and imported it into the Computer account’s Personal Certificates store of the UAG server. Select both certificates and click Finish.

			[[File:Example.jpg]]

	It may be appropriate to point out here that IP-HTTPS, while it is the least desierable connection method due to it’s overhead, it is incredibly useful since it is the option most likely to work in “unusual” scenarios due to popular support for connecting to secure web sites through firewalls. When it comes to the configuration of the UAG server, it does proxy all IP-HTTPS trafic through a local instance of IIS. To accomplish this the UAG Wizard seems to wipe and re-write the IIS settings when activating the UAG configuration. Why is that important? Well, you should not expect to be able to use the IIS installation on the UAG server for anything other than IP-HTTPS. So don’t bother adding another site or try to bind one to a different IP or even make some subdirectories in any existing site. UAG will destroy it and it doesn’t tell you about it either.		It may be appropriate to point out here that IP-HTTPS, while it is the least desierable connection method due to it’s overhead, it is incredibly useful since it is the option most likely to work in “unusual” scenarios due to popular support for connecting to secure web sites through firewalls. When it comes to the configuration of the UAG server, it does proxy all IP-HTTPS trafic through a local instance of IIS. To accomplish this the UAG Wizard seems to wipe and re-write the IIS settings when activating the UAG configuration. Why is that important? Well, you should not expect to be able to use the IIS installation on the UAG server for anything other than IP-HTTPS. So don’t bother adding another site or try to bind one to a different IP or even make some subdirectories in any existing site. UAG will destroy it and it doesn’t tell you about it either.

Akulikov: /* Konfigureerimise viisard: DirectAccess server */

2011-04-01T19:14:50Z

Konfigureerimise viisard: DirectAccess server

← Older revision		Revision as of 22:14, 1 April 2011
Line 44:		Line 44:
	=== Konfigureerimise viisard: DirectAccess server ===		=== Konfigureerimise viisard: DirectAccess server ===

	~~Selleks~~, ~~et alustada serveri konfigureerimist, vajutage nuppu~~ Edit DirectAccess Server ~~gruppis~~.		Getting through the DirectAccess Server wizard might be the most challenging becuase it’s behaviour and what it asks for is determined by some dependancy checks that the wizard does in the background. To get started, click the Edit button in the DirectAccess Server group.

			NOTE: At the time of this writting, Forefront UAG Update 1 and earlier has a known bug in this particular wizard that can appear when you reach the page about selecting certificates. Microsoft delevopers are aware of the issue as discussed here in the Microsoft Forefront forum but I have been told that there won’t be a fix until UAG Service Pack 1 due for release around the end of 2010. It seems to be fine the first time you go through the wizard but if you select one certificate type and then rerun the wizard and select the other type the wizard will peg the CPU at 100% on the third and any subsequent times that you run the wizard. So the moral of the story here is to get it right the first time and you’ll be fine. Otherwise you may need to wipe the entire UAG Configuration (by running configmgrutil -del) and start all over.



			Remember, I am assuming that your internal network infrastructure is running purely IPv4. With that in mind, the first page of this wizard will sort of tell you if you have things set up right…but you have to know what you are looking for. If you notice that the dropdown list for IPv4 is disabled, then you’re missing something. It looks like this:



			This usually means the wizard was unable to find an ISATAP router and assumes you are using IPv6 on your internal network becuase, well, without ISATAP to convert IPv6 into IPv4 you would need native IPv6 for DirectAccess to work. Since we do not have IPv6 internally and we want to use ISATAP, there are two things to check in order to correct this:
			1.Make sure ISATAP has been removed from the DNS Global Block List (here’s how)
			2.Make sure you have an “A record” in DNS for “ISATAP” that points to the internal IP address of your UAG server.

	Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.		Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.



	The two dropdown lists should be populated with only one option in each. In the left DDL for the Internet-facing IPv4 address select the first public IP on your server and then you should see the second address appear underneath the drop-down. In the right DDL for the Internal IPv4 address select the server’s intranet address and then the wizard should tell you that it will be enabling ISATAP and that you should create the DNS record for ISATAP. Of course that’s a little ironic being that you needed to do that beforehand.		The two dropdown lists should be populated with only one option in each. In the left DDL for the Internet-facing IPv4 address select the first public IP on your server and then you should see the second address appear underneath the drop-down. In the right DDL for the Internal IPv4 address select the server’s intranet address and then the wizard should tell you that it will be enabling ISATAP and that you should create the DNS record for ISATAP. Of course that’s a little ironic being that you needed to do that beforehand.



	Next leave both NAT64 and DNS64 checked. If you don’t you will either need to configure your own services or be unable to connect to IPv4 targets. So, yeah, leave those checked.		Next leave both NAT64 and DNS64 checked. If you don’t you will either need to configure your own services or be unable to connect to IPv4 targets. So, yeah, leave those checked.



	Finally, you need to select the select the certificate for the server that is issuing the certs to your enterprise. At this point you should have already generated a web certificate to be used for IP-HTTPS and imported it into the Computer account’s Personal Certificates store of the UAG server. Select both certificates and click Finish.		Finally, you need to select the select the certificate for the server that is issuing the certs to your enterprise. At this point you should have already generated a web certificate to be used for IP-HTTPS and imported it into the Computer account’s Personal Certificates store of the UAG server. Select both certificates and click Finish.



	It may be appropriate to point out here that IP-HTTPS, while it is the least desierable connection method due to it’s overhead, it is incredibly useful since it is the option most likely to work in “unusual” scenarios due to popular support for connecting to secure web sites through firewalls. When it comes to the configuration of the UAG server, it does proxy all IP-HTTPS trafic through a local instance of IIS. To accomplish this the UAG Wizard seems to wipe and re-write the IIS settings when activating the UAG configuration. Why is that important? Well, you should not expect to be able to use the IIS installation on the UAG server for anything other than IP-HTTPS. So don’t bother adding another site or try to bind one to a different IP or even make some subdirectories in any existing site. UAG will destroy it and it doesn’t tell you about it either.		It may be appropriate to point out here that IP-HTTPS, while it is the least desierable connection method due to it’s overhead, it is incredibly useful since it is the option most likely to work in “unusual” scenarios due to popular support for connecting to secure web sites through firewalls. When it comes to the configuration of the UAG server, it does proxy all IP-HTTPS trafic through a local instance of IIS. To accomplish this the UAG Wizard seems to wipe and re-write the IIS settings when activating the UAG configuration. Why is that important? Well, you should not expect to be able to use the IIS installation on the UAG server for anything other than IP-HTTPS. So don’t bother adding another site or try to bind one to a different IP or even make some subdirectories in any existing site. UAG will destroy it and it doesn’t tell you about it either.

Akulikov: /* Konfigureerimise viisard: DirectAccess server */

2011-03-29T08:51:23Z

Konfigureerimise viisard: DirectAccess server

← Older revision		Revision as of 11:51, 29 March 2011
Line 44:		Line 44:
	=== Konfigureerimise viisard: DirectAccess server ===		=== Konfigureerimise viisard: DirectAccess server ===

	Getting through the DirectAccess Server wizard might be the most challenging becuase it’s behaviour and what it asks for is determined by some dependancy checks that the wizard does in the background. To get started, ~~click the~~ Edit ~~button in the~~ DirectAccess Server ~~group~~.		Selleks, et alustada serveri konfigureerimist, vajutage nuppu Edit DirectAccess Server gruppis.

	Remember, I am assuming that your internal network infrastructure is running purely IPv4. With that in mind, the first page of this wizard will sort of tell you if you have things set up right…but you have to know what you are looking for. If you notice that the dropdown list for IPv4 is disabled, then you’re missing something. It looks like this:

	This usually means the wizard was unable to find an ISATAP router and assumes you are using IPv6 on your internal network becuase, well, without ISATAP to convert IPv6 into IPv4 you would need native IPv6 for DirectAccess to work. Since we do not have IPv6 internally and we want to use ISATAP, there are two things to check in order to correct this:

	~~Make sure ISATAP has been removed from the DNS Global Block List~~
	~~Make sure you have an “A record” in DNS for “ISATAP” that points to the internal IP address of your UAG server.~~

	Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.		Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.

Akulikov: /* DirectAccess konfigureerimine */

2011-03-28T16:45:39Z

DirectAccess konfigureerimine

← Older revision		Revision as of 19:45, 28 March 2011
Line 26:		Line 26:
	*On the Installation Results lehel vajutage Close.		*On the Installation Results lehel vajutage Close.

	==DirectAccess ~~konfigureerimine~~==		==DirectAccess haldamine==

	=== Konfigureerimise viisard: Klient ===		=== Konfigureerimise viisard: Klient ===

Akulikov: /* Konfigureerimise viisard: DirectAccess server */

2011-03-28T16:43:13Z

Konfigureerimise viisard: DirectAccess server

← Older revision		Revision as of 19:43, 28 March 2011
Line 44:		Line 44:
	=== Konfigureerimise viisard: DirectAccess server ===		=== Konfigureerimise viisard: DirectAccess server ===

			Getting through the DirectAccess Server wizard might be the most challenging becuase it’s behaviour and what it asks for is determined by some dependancy checks that the wizard does in the background. To get started, click the Edit button in the DirectAccess Server group.

			Remember, I am assuming that your internal network infrastructure is running purely IPv4. With that in mind, the first page of this wizard will sort of tell you if you have things set up right…but you have to know what you are looking for. If you notice that the dropdown list for IPv4 is disabled, then you’re missing something. It looks like this:

			This usually means the wizard was unable to find an ISATAP router and assumes you are using IPv6 on your internal network becuase, well, without ISATAP to convert IPv6 into IPv4 you would need native IPv6 for DirectAccess to work. Since we do not have IPv6 internally and we want to use ISATAP, there are two things to check in order to correct this:

			Make sure ISATAP has been removed from the DNS Global Block List
			Make sure you have an “A record” in DNS for “ISATAP” that points to the internal IP address of your UAG server.

			Once you have the DNS considerations for ISATAP taken care of you should see that IPv6 is now grey’d out and the IPv4 dropdown is enabled.

			The two dropdown lists should be populated with only one option in each. In the left DDL for the Internet-facing IPv4 address select the first public IP on your server and then you should see the second address appear underneath the drop-down. In the right DDL for the Internal IPv4 address select the server’s intranet address and then the wizard should tell you that it will be enabling ISATAP and that you should create the DNS record for ISATAP. Of course that’s a little ironic being that you needed to do that beforehand.

			Next leave both NAT64 and DNS64 checked. If you don’t you will either need to configure your own services or be unable to connect to IPv4 targets. So, yeah, leave those checked.

			Finally, you need to select the select the certificate for the server that is issuing the certs to your enterprise. At this point you should have already generated a web certificate to be used for IP-HTTPS and imported it into the Computer account’s Personal Certificates store of the UAG server. Select both certificates and click Finish.

			It may be appropriate to point out here that IP-HTTPS, while it is the least desierable connection method due to it’s overhead, it is incredibly useful since it is the option most likely to work in “unusual” scenarios due to popular support for connecting to secure web sites through firewalls. When it comes to the configuration of the UAG server, it does proxy all IP-HTTPS trafic through a local instance of IIS. To accomplish this the UAG Wizard seems to wipe and re-write the IIS settings when activating the UAG configuration. Why is that important? Well, you should not expect to be able to use the IIS installation on the UAG server for anything other than IP-HTTPS. So don’t bother adding another site or try to bind one to a different IP or even make some subdirectories in any existing site. UAG will destroy it and it doesn’t tell you about it either.

	===Mõned näidis laborid Microsofti veebist:===		===Mõned näidis laborid Microsofti veebist:===

Akulikov: /* Konfigureerimise viisard: Klient */

2011-03-28T16:42:03Z

Konfigureerimise viisard: Klient

← Older revision		Revision as of 19:42, 28 March 2011
Line 40:		Line 40:
	Teie saate panna mitu gruppi siia, aga mugavam on lisada ühe gruppi ja siis hiljem juba muuta arvutite nimekirja otse Active Directory alt.		Teie saate panna mitu gruppi siia, aga mugavam on lisada ühe gruppi ja siis hiljem juba muuta arvutite nimekirja otse Active Directory alt.

	Click finish and you’re done! Keep in mind that if you already have a configuration in place then changing this setting will not automatically enable a new group for DirectAccess. The configuration will need to be Generated AND Activated, then the client computers will also need to fetch the new policy, as is the case with any other changes to the UAG configuration. If this is the first time you’re running through this configuration don’t worry about activating the configuration just yet. You have pleanty more to run through first.		Vajutage Finish nuppu ja sellega algne seadistus saab tehtud.

	=== Konfigureerimise viisard: DirectAccess server ===		=== Konfigureerimise viisard: DirectAccess server ===