Archive

Posts Tagged ‘missing’

Quickie: Missing WDS/RIS Extension in ADUC on Windows 2008 R2 and Windows Server 2012

April 10th, 2013 2 comments

At one customer I upgraded domain controller into Windows Server 2008 R2. This customer use two RIS (Windows 2003) and one WDS (Windows 2008 R2) servers to deploy OS images.

Problem

Customer complained that before upgrade of domain controllers to Windows Server 2008 R2, he could provision computer accounts for RIS/WDS. After domain controllers were upgraded user  creates Computer account in ADUC (Active Directory Users and Computers), but he sees only one screen to define computer name.

Create new account

He couldn’t define GUID/UUID and couldn’t specify remote installation server.

Solution

To be able to prestage computer accounts for RIS/WDS server you need to install Feature called Remote Server Administration Tools — Role Administration Tools — Windows Deployment Services Tools.

Windows Server 2008 R2:

WDS Tools

Windows Server 2012:

Install feature

Or by using PowerShell in Windows Server 2012:

Install-WindowsFeature WDS-AdminPack

When you install this feature you can define GUID/UUID:

Define GUID/UUID

and also specify remote installation server:

Define remote installation server

That’s all,

Exchange not seeing all domain controllers from AD

November 30th, 2012 No comments

I had to solve interesting problem today at one of our customer. Here is a short preview of customer’s environment:

AD Topology

Customer has following 5 sites:

  • Site1 – containing 1 DC
  • Site2 – containing 1 DC (one has PDC FSMO role)
  • Site3 – containing 2 DCs. Let’s call this central site.
  • Site4 – containing 2 DCs. This site represents one datacenter (datacenter 1)
  • Site5 – containing 2 DCs. This site represents one datacenter (datacenter 2)

All domain controllers are Global Catalogs. Replication was set manually. It’s configured to be in star topology with median in Site3. For each connection was defined newInter-Site Transport in AD Sites.

AD Topology

AD Topology

Replication works fine. Exchange servers are able to resolve all domain controler. I have checked this using DNS and also nltest.

Exchange Topology

There are four Exchange 2012 servers. Two are CAS/HUB servers put into CAS Array. CAS Servers and CAS Array IP addresses belong to Site4 IP Subnet. And two Mailbox server that are put into DAG. Both mailbox server and DAG IP addresses are in Site4. Problem is that one CAS/HUB and one Mailbox server are physically located in Site4 and one CAS/HUB and one Mailbox server are located physically in Site5. Between Site4 and Site5 are L2 networks for CAS/HUB and Mailbox server.

Exchange topology

Exchange topology

Everything works fine. All IP subnets are assigned to Site4 which means all Exchange servers use primary Global Catalog functionality from domain controller from Site4. Idea from network/security guys was to allow Exchange servers to use Global Catalog just from domain controllers located in datacenters – Site4 and Site5. So firewalls don’t let Exchange server to use Global Catalog from other domain controller besides those located in Site4 and Site5.

Problem

Problem appeared when domain controllers in Site4 went down. Exchange servers didn’t want to start and mount databases.

When we looked into Events we could see event 2080 which stated that Exchange AD Topology service sees just four domain controllers:

  • Two in-site domain controllers from same site IP subnet are in (Site4)
  • Two out-of-site domain controllers. Controllers only from central site Site3

Exchange didn’t use those out-of-site domain controllers, because firewalls blocked it – regarding network/security guys recomendations. Question was why exchange servers didn’t see and use other domain controllers? It sees and uses only those four domain controllers (two in same AD site and two from central site).

After couple of minutes discusing with my coleague we find out that Exchange copies AD topology and it uses domain controllers in following way:

  • Primary uses domain controllers in same site as Exchange services are located – in-site DC
  • Secondary uses only domain controller which are directly replicating with domain controllers from primary site  – out-of-site DC

My colleague tried to convince me to believe it’s good idea and Exchange tries to protect you from some problems. But I don’t see any point of Exchange not contacting all domain controllers and contacing only domain controllers in the site and contacting domain controlers which replicate with domain controllers in site. I don’t see a poing of Exchange not trying to connect to Global Catalogs in Site1, Site2 and Site5. So this is the way Exchange looks for Global Catalog servers by design.

Proof of problem 🙂

I’ve done couple testing scenarios.

Exchange servers in Site4

  • In-site DCs: DCs from Site4
  • Out-of-site DCs: DCs only from Site3

Exchange servers in Site5

  • In-site DCs: DCs from Site5
  • Out-of-site DCs: DCs only from Site3

Exchange servers in Site1

  • In-site DCs: DC from Site1
  • Out-of-site DCs: DCs only from Site3

Exchange servers in Site3

  • In-site DCs: DCs from Site3
  • Out-of-site DCs: all DCs from all sites

This is really proof of problem with Exchange locating DCs.

 

Solution

To solve this issue we could make two things:

  • Create new AD Site only for all Exchange IP Subnets and add two domain controllers into this new created AD Site. One DC would be located in physical location 1/datacenter 1 (with CAS1 and MBX1 servers) and other DC would be located in physical location 2/datacenter 2 (with CAS2 and MBX2 servers).
  • Create new AD Inter-site Transport between Site4 and Site5.

We decided to create new AD Inter-site Transport.

I still don’t understand why Exchange doesn’t use all domain controllers in AD domain as I would think it would 🙁

Windows Missing Administrative Shares

August 12th, 2011 2 comments

Today I went to one of our customers and they were complaining about not being able to access admin shares on their clients’ computers. Admin shares are those following:

Read more…