官术网_书友最值得收藏!

Hostname and domain membership

Now that our network traffic is flowing, we need to finalize a couple of other regular items on the DirectAccess server. First is setting the hostname. While this seems like a menial, regular task, don't take it lightly. It is recommended that once your hostname is set, it should not be changed in the future. So choose the name carefully, and choose a name that meets your naming standards. It is not recommended to change the hostname of a DirectAccess server, because there are items external to the server itself which are bound to that particular name, such as Group membership, Group Policy Objects (GPOs) filtering, and certificates. A change in the hostname of a DirectAccess server will result in a number of external factors needing to be changed, adjusted, or reissued, and there is a huge potential for problems. So all that to say—choose your name wisely and don't think you can name it DA-Test for now, and simply rename it later.

Once your name is set, it is time to join it to the domain. This is required for DirectAccess to work, as the solution is tightly integrated with Active Directory. You do not have to join it to the same domain as the rest of your internal network or the same domain as the DirectAccess client machines, but whatever domain you join it to must have a two-way trust to those domains, so that traffic can flow successfully between the DirectAccess server and the resources with which it is going to interact.

Prestage the computer account

I highly recommend prestaging the computer account for your DirectAccess server(s) in Active Directory before you join them to the domain. This is not required, but I recommend it because I have seen many cases where upon joining the domain, a DirectAccess server had some existing GPOs applied to it which disabled items in Windows that are necessary for DirectAccess to function. What I see most often are GPOs in place on the network which disable or make changes to the Windows Firewall, and if any of these policies get applied to your DirectAccess servers, it will certainly interfere with operability.

Try your best to make sure that no existing polices get applied to the servers at all. It is best to create a separate Organizational Unit (OU) for them to reside in, which blocks the inheritance of existing policies. In the end, there are going to be policies that need to apply to them, the actual DirectAccess Server policy for example, but try to keep them as clean as possible from changes. Once you have DirectAccess connectivity established and working, you can try applying your policies one at a time if you so choose, but keep in mind that if a GPO gets applied and changes are made, then simply removing the device from that GPO's filtering doesn't always reverse the settings that were changed. It is possible that you could break the DirectAccess server to the point that the quickest resolution is to re-prep the server and start over, so tread lightly here.

主站蜘蛛池模板: 葵青区| 南阳市| 兴国县| 杂多县| 改则县| 新营市| 娱乐| 会理县| 阳信县| 阳原县| 扎赉特旗| 灵台县| 资源县| 海淀区| 望城县| 弥勒县| 寿宁县| 曲麻莱县| 增城市| 额济纳旗| 南岸区| 大港区| 商城县| 临澧县| 志丹县| 普兰店市| 崇州市| 马边| 东山县| 申扎县| 青川县| 禹城市| 翁源县| 永嘉县| 安图县| 锡林浩特市| 南江县| 镇坪县| 巴青县| 湛江市| 中阳县|