AD中创建OU必须用dsadd ou或PowerShell，图形界面不支持批量嵌套；OU命名须与HR系统一致、禁用特殊字符、避免同名混淆；移动对象后需检查GPO继承与链接；OU结构变更风险极高，应冻结名称、用Description存HR编码，同步脚本只查不改。
AD中创建OU必须用dsadd ou或PowerShell，图形界面不支持批量嵌套
图形化工具（如“active directory 用户和计算机”）能点出单个ou，但企业级行政架构往往有“总部→大区→省公司→地市分公司”多层嵌套，手动逐级右键新建效率低、易漏层级、无法标准化命名。真正落地时得靠命令行或脚本。
-
dsadd ou适合简单场景，例如：dsadd ou "OU=华东大区,DC=corp,DC=local"；注意DN顺序是自右向左（域在最右），写反会报错0x2098: The specified directory service attribute or value does not exist. - PowerShell更可控，推荐用
New-ADOrganizationalUnit，支持-ProtectedFromAccidentalDeletion $true防误删，且能通过-Path参数直接指定父容器，避免手算DN - 别在
Users或Computers容器下直接建OU——它们是特殊容器，不是真正的OU，无法应用组策略，也不能作为其他OU的父节点
OU命名必须与HR系统对齐，不能照搬IT术语
很多团队起名用OU=ServerAdmins或OU=Win10Devices，这看起来“技术清晰”，但行政架构映射的核心是人和汇报关系，不是设备类型或权限角色。一旦HR调整部门，AD里就得大规模迁移对象，触发同步中断、GPO失效、权限重配。
- 名称应严格匹配HR系统中的组织单元全称，例如
OU=江苏省南京市分公司，而非OU=NJ-Branch或OU=JS-NJ - 避免空格、斜杠、括号等特殊字符；中文可读性强，AD本身完全支持，且
Get-ADOrganizationalUnit等命令能正常过滤 - 如果存在同名部门（如多个“研发中心”），必须加前缀区分归属，例如
OU=集团研发中心vsOU=华东研发中心，不能靠位置隐含逻辑
把用户/计算机移入OU后，组策略不会立即生效，需检查继承链和阻断设置
很多人执行完Move-ADObject就以为GPO自动接管了，结果发现桌面背景没变、软件没推、密码策略没生效。根本原因是：组策略应用依赖完整的继承路径，而默认情况下，上级OU可能启用了Block Inheritance，或者当前OU设置了Enforced策略但没链接到正确GPO。
- 用
gpresult /h report.html /scope computer查实际生效的GPO列表，确认目标OU是否出现在“Applied Group Policy Objects”里 - 在“Active Directory 用户和计算机”中右键OU → “属性” → “组策略”页签，看是否有GPO链接；若为空，需手动添加，不能依赖父级继承
- 特别注意
Domain ControllersOU：它默认启用Block Inheritance，新创建的行政OU绝不能把它当父容器，否则DC对象无法接收任何自定义策略
同步HR系统时，OU结构变更比用户属性变更更危险
HR系统导出员工姓名、邮箱、电话这些字段出错，顶多影响通讯录显示；但一旦把“北京分公司”改名为“华北运营中心”，并在AD中重命名对应OU，所有该OU下的用户、组、计算机对象都会脱离原GPO作用域，且Move-ADObject操作不可回滚——AD不记录移动前路径，审计日志只记DN变更，不记语义。
- 建议OU名称冻结，用
Description属性存HR系统里的最新部门编码或别名，例如Set-ADOrganizationalUnit -Identity "OU=北京市分公司" -Description "HR_CODE:BJ-OPS-2024" - 自动化同步脚本里，对OU只做“查是否存在”，不做“重命名”或“重建”；新增OU走审批流程人工介入，避免脚本误覆盖
- 跨域迁移或合并时，优先用
Move-ADObject平移整个OU树，而不是导出再导入——后者会丢失SID历史、组成员关系和ACL继承状态
