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

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.

主站蜘蛛池模板: 巴南区| 新民市| 黄陵县| 乌海市| 大新县| 奉新县| 金溪县| 鹤庆县| 兴化市| 新巴尔虎右旗| 郧西县| 桐城市| 焉耆| 马龙县| 同江市| 抚远县| 定远县| 洞口县| 许昌县| 泰顺县| 恩施市| 夹江县| 霍林郭勒市| 彰化市| 西城区| 盖州市| 许昌县| 罗源县| 湘阴县| 塔河县| 五河县| 长白| 西乡县| 罗源县| 井研县| 泰兴市| 阿拉善右旗| 东丰县| 沙田区| 荔波县| 辽源市|