Jaxidian's questions

I have a pair of active directory domains with a one-way trust where I am attempting to revive some servers (~12, so automated steps would be handy but I can manually do everything if necessary) that have been offline for 2+ years.

The good news:

1. The AD servers themselves have been online and appear healthy enough on both domains!
2. Cached credentials seem to be working well enough that I can easily access all servers as an administrator.

The bad news:

1. These servers have been offline for ~2 years. I'm sure they're no longer valid in AD.
2. These servers run a variety of software such as SQL Server, TFS, and some other things.

Additional info:

• I'm not looking to get everything up and running for a long period of time.
• If I can get these up and running for ~1-2 months while we migrate everything away, then I can decommission much of what's here.
• Despite the plan of decommissioning these, I would really like to get some of these up and running in a fully-functional way for this short period of time.
• All server OSes are either Windows Server 2008 or 2008 R2 (I think all are Standard edition). Nearly all are running within Hyper-V, so I have some very convenient backup/restore options as long as AD doesn't catch me doing it.
• My admin credentials are on the domain that both domains trust. I currently am not using any credentials from the "child domain" (I know, incorrect name but I think you understand in this limited situation what I mean).
• Prior to everything going offline, WSUS was setup and running (via SCE 2007). However, that server has a DB that's been corrupted. Instead of trying to recover that, I've just written it off. It appears they used a .reg file to set some keys in HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate and in [same]\AU pointing to the WSUS server.

Questions:

1. Clearly I'll need to renew their registrations in AD. Is this best done on the client-side or within AD itself somehow? My question had wrong assumptions. As joeqwerty explains, this is not a problem.
2. If I'm renewing their registrations in AD, are there any special concerns specifically with SQL Server and/or TFS to keep them healthy through the re-registration? (downtime is okay but I don't want to have to reconfigure all of the SQL Server and/or TFS software through this process) My question had wrong assumptions. As joeqwerty explains, this is not a problem.
3. What is the best way to get these ~12 servers to hit Microsoft's servers for Windows Updates instead of the defunct WSUS server?

Thanks for the help!! :-)

I have a Windows 2012 R2 Essentials box I'm building (should be the same concerns as a Server 2012 or Server 2012 R2 box). I'm attempting to mirror the system disk (identical 750GB SATA drives) but I can never get a successful mirrored volume created!

How I do it:

1. In Disk Management, right-click on my system disk (a single partition) and chose Add Mirror...
2. Chose my second drive (it was Online and Unallocated)
3. It gives me the prompt about not booting other boot volumes on dymanic drives and I click through that.
4. Within a few seconds, within the first screen refresh that shows the mirroring, both drives are immediately in a "Failed Redundancy" state. They NEVER make it to the "Regenerating" or any other seemingly-valid state.

At this point, the event log gives me an Event ID 142:

Extent Disk2-01 on disk {guid} that is part of the fault-tolerant volume C: is no longer accessible.

• both disks are Online
• the second disk works just fine as a normal individual drive
• both disks pass typical SMART tests
• both disks pass extended tests from manufacturer utilities
• using the Reactivate Volume option doesn't change anything
• removing and recreating the mirrored volume doesn't change anything

I don't know what else to do to get this software RAID1 setup. Help!

I ran some tests in dev with the ADFS Proxy and it worked beautifully. However, now that I'm in a more-rigid environment (a staging environment), I'm having difficulties setting up a proxy. The errors I get from the AD FS 2.0 Federation Server Proxy Configuration Wizard:

The AD FS 2.0 Federation Server Configuration Wizard requires either (a) the Default Web Site to be present in IIS or (b) only one Web site to be present in IIS.

We don't meet either requirement. We have two web sites: 1) MVC (http/https) with a custom name and 2) WCF services (net.pipe/tcp). Is there any way to specify a Web Site for the wizard to target?

If I could simply tell it to install into our MVC's web site, all would be well. Otherwise, I'll have to tear down our WCF services' site to get this to install, which I REALLY don't want to tear it down and rebuild it afterwards. This seems like a ridiculous requirement and there SHOULD be a "Web Site Picker" for this wizard so I can tell it where to deploy. Do they REALLY think enterprises utilizing ADFS deploy their apps to "Default Web Site"? Really??

In our development environment, we're having a problem with our configured Relying Parties in ADFS 2.0 that is baffling me. It's acting as though there is a blacklist of identifiers.

We have 3 developers developing against this right now (new configuration on Win2kR2 for ADFS, Win7 Pro/VS2010/MVC2/C# for devs). ADFS is on Domain2 while all dev boxes are on Domain1. Domain2 trusts Domain1 but not the other way around (not that this matters). I created 3 trusts, one for each developer. The trust endpoint and identifiers are the same for each developer (https://DevBoxFQDN/AppName/). When initially setting this up, I was just using DevA as a test case until I got it to work. Once it worked for DevA, I then added DevB but did it incorrectly by adding DevB's identifier to the DevA RP. The end result was when you tried to authenticate on DevB's web app, when redirected back to the app, it went to DevA's box. Messed up configuration, but I would call that a success test case for the DevB box. Once I realized this, I removed DevB's identifier from the DevA RP and created both the DevB and DevC RPs (pointing to https://DevB.FQDN/AppName/ and https://DevC.FQDN/AppName/ for both endpoints and identifiers).

At this point, something strange happened. This worked for DevC just fine, like it does for DevA. However, DevB gets the Event IDs 184/364 indicating that the DevB identifier is incorrect. Much debugging and googling of possible problems resulted in nothing useful. As a blind stab, we simply created a new Virtual Directory on the DevB box for https://DevB.FQDN/AppName2/ (we literally just added a 2 to the end of the virtual directory/application name - points to the same location as the other one and has the same settings) and made the same change to the web.config file for the app. In ADFS, I edited the endpoint and identifier to add the 2 as well. This change and this change alone causes DevB to function properly. So this debunks most of the possibilities that we have suspected don't apply to us (firewalls, screwed up certificates/SPNs, etc.) that the forum posts left for us. If we change this back to remove the 2, then it breaks again. Nothing Else Changes!

And just to be thorough, we reverted the DevB machine back to an imaged-based backup from the time when it was "working" but under the DevA RP - no change. So this says to me that the problem is somewhere on the configuration of the ADFS server or something in between, but not the web server.

So, what's the deal? Why won't ADFS work with a specific identifier/endpoint (simply a string URL for as much as I can tell) but if I simply add a 2 to it in all cases, it works? Is there a blacklist/cache or something that I need to clear?

Two events are logged: 184 and 364. The 364 is of no interest as it simply says "something went wrong" but the 184 is of interest. The event log details of the error (Event ID: 184):

A token request was received for a relying party identified by the key
   'https://DevB.FQDN/AppName/', but the request could not be fulfilled
   because the key does not identify any known relying party trust. 
Key: https://DevB.FQDN/AppName/ 

This request failed. 

User Action 
If this key represents a URI for which a token should be issued, verify
   that its prefix matches the relying party trust that is configured in
   the AD FS configuration database.

And lastly, I have double/triple/quintuple-checked the identifier. It IS correct with no typos or anything.

PS: This is a cross-post from Microsoft's Forums for this problem.

I have two domain controllers:

DC1: Win2k3 R2 EGDC1: Win2k8 R2

When I try to replicate these two (via Manage Sites and Services and under NTDS Settings) by selecting Replicate Now, I get the error message The RPC Server is unavailable. It doesn't matter if I try this while remoted into DC1 or DC2.

According to this technet article, this is a problem with a machine being down. However, I can additionally have both domain controllers ping one another just fine so there is no DNS issue nor any connectivity issue. Both are on the same LAN and even on the same subnet, so no VPN/wifi/firewall/quirky issues like that should be a problem.

Additionally, I verified that the RPC service is running on both boxes.

What could the problem be and how would I fix it?

dcdiag results:

Directory Server Diagnosis

Performing initial setup:
   Trying to find home server...
   Home Server = EGDC1
   * Identified AD Forest.
   Ldap search capabality attribute search failed on server DC1, return value =
   81
   Got error while checking if the DC is using FRS or DFSR. Error:
   Win32 Error 81The VerifyReferences, FrsEvent and DfsrEvent tests might fail
   because of this error.
   Done gathering initial info.

Doing initial required tests

   Testing server: INF\EGDC1
      Starting test: Connectivity
         ......................... EGDC1 passed test Connectivity

Doing primary tests

   Testing server: INF\EGDC1
      Starting test: Advertising
         ......................... EGDC1 passed test Advertising
      Starting test: FrsEvent
         ......................... EGDC1 passed test FrsEvent
      Starting test: DFSREvent
         ......................... EGDC1 passed test DFSREvent
      Starting test: SysVolCheck
         ......................... EGDC1 passed test SysVolCheck
      Starting test: KccEvent
         ......................... EGDC1 passed test KccEvent
      Starting test: KnowsOfRoleHolders
         [DC1] DsBindWithSpnEx() failed with error 1722,
         The RPC server is unavailable..
         Warning: DC1 is the Schema Owner, but is not responding to DS RPC
         Bind.
         Warning: DC1 is the Schema Owner, but is not responding to LDAP Bind.
         Warning: DC1 is the Domain Owner, but is not responding to DS RPC
         Bind.
         Warning: DC1 is the Domain Owner, but is not responding to LDAP Bind.
         Warning: DC1 is the PDC Owner, but is not responding to DS RPC Bind.
         Warning: DC1 is the PDC Owner, but is not responding to LDAP Bind.
         Warning: DC1 is the Rid Owner, but is not responding to DS RPC Bind.
         Warning: DC1 is the Rid Owner, but is not responding to LDAP Bind.
         Warning: DC1 is the Infrastructure Update Owner, but is not responding
         to DS RPC Bind.
         Warning: DC1 is the Infrastructure Update Owner, but is not responding
         to LDAP Bind.
         ......................... EGDC1 failed test KnowsOfRoleHolders
      Starting test: MachineAccount
         ......................... EGDC1 passed test MachineAccount
      Starting test: NCSecDesc
         Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have
            Replicating Directory Changes In Filtered Set
         access rights for the naming context:
         DC=ForestDnsZones,DC=eg,DC=local
         Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have
            Replicating Directory Changes In Filtered Set
         access rights for the naming context:
         DC=DomainDnsZones,DC=eg,DC=local
         ......................... EGDC1 failed test NCSecDesc
      Starting test: NetLogons
         ......................... EGDC1 passed test NetLogons
      Starting test: ObjectsReplicated
         ......................... EGDC1 passed test ObjectsReplicated
      Starting test: Replications
         [Replications Check,EGDC1] A recent replication attempt failed:
            From DC1 to EGDC1
            Naming Context: DC=ForestDnsZones,DC=eg,DC=local
            The replication generated an error (1256):
            The remote system is not available. For information about network tr
oubleshooting, see Windows Help.

            The failure occurred at 2010-11-29 08:56:33.
            The last success occurred at 2010-10-05 01:10:06.
            1330 failures have occurred since the last success.
         [Replications Check,EGDC1] A recent replication attempt failed:
            From DC1 to EGDC1
            Naming Context: DC=DomainDnsZones,DC=eg,DC=local
            The replication generated an error (1256):
            The remote system is not available. For information about network tr
oubleshooting, see Windows Help.

            The failure occurred at 2010-11-29 08:56:33.
            The last success occurred at 2010-10-05 01:10:03.
            1330 failures have occurred since the last success.
         [Replications Check,EGDC1] A recent replication attempt failed:
            From DC1 to EGDC1
            Naming Context: CN=Schema,CN=Configuration,DC=eg,DC=local
            The replication generated an error (1722):
            The RPC server is unavailable.
            The failure occurred at 2010-11-29 08:57:15.
            The last success occurred at 2010-10-05 00:48:18.
            1330 failures have occurred since the last success.
            The source remains down. Please check the machine.
         [Replications Check,EGDC1] A recent replication attempt failed:
            From DC1 to EGDC1
            Naming Context: CN=Configuration,DC=eg,DC=local
            The replication generated an error (1722):
            The RPC server is unavailable.
            The failure occurred at 2010-11-29 08:56:54.
            The last success occurred at 2010-10-05 00:48:18.
            1330 failures have occurred since the last success.
            The source remains down. Please check the machine.
         [Replications Check,EGDC1] A recent replication attempt failed:
            From DC1 to EGDC1
            Naming Context: DC=eg,DC=local
            The replication generated an error (1722):
            The RPC server is unavailable.
            The failure occurred at 2010-11-29 08:56:33.
            The last success occurred at 2010-10-05 01:09:58.
            1331 failures have occurred since the last success.
            The source remains down. Please check the machine.
         ......................... EGDC1 failed test Replications
      Starting test: RidManager
         ......................... EGDC1 failed test RidManager
      Starting test: Services
         ......................... EGDC1 passed test Services
      Starting test: SystemLog
         ......................... EGDC1 passed test SystemLog
      Starting test: VerifyReferences
         ......................... EGDC1 passed test VerifyReferences


   Running partition tests on : ForestDnsZones
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones passed test CheckSDRefDom
      Starting test: CrossRefValidation
         ......................... ForestDnsZones passed test
         CrossRefValidation

   Running partition tests on : DomainDnsZones
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones passed test CheckSDRefDom
      Starting test: CrossRefValidation
         ......................... DomainDnsZones passed test
         CrossRefValidation

   Running partition tests on : Schema
      Starting test: CheckSDRefDom
         ......................... Schema passed test CheckSDRefDom
      Starting test: CrossRefValidation
         ......................... Schema passed test CrossRefValidation

   Running partition tests on : Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration passed test CheckSDRefDom
      Starting test: CrossRefValidation
         ......................... Configuration passed test CrossRefValidation

   Running partition tests on : eg
      Starting test: CheckSDRefDom
         ......................... eg passed test CheckSDRefDom
      Starting test: CrossRefValidation
         ......................... eg passed test CrossRefValidation

   Running enterprise tests on : eg.local
      Starting test: LocatorCheck
         ......................... eg.local passed test LocatorCheck
      Starting test: Intersite
         ......................... eg.local passed test Intersite

I have a one-way domain trust setup and it's working if I want to deal with users on a per-user basis from the trusted domain. Let's say we have 'Parent.Domain.com' and 'Child.Domain.com' where Child trusts Parent but Parent does not trust Child - aside from this trust, the two domains are 100% unrelated. For all servers within Child, I can now specify permissions for users in Parent, so that tells me that the trust is working.

Now I'd like to take it to the next level and start setting up permissions domain-wide within Child for my Parent users and groups, but this is where I'm failing. The first thing I wanted to do was have all Domain Admins within Parent also be in the Domain Admins group in Child. However, when I go to add this membership to the Child's Domain Admins group, I can't see anything from my Parent domain, groups nor users (I simply don't see Parent.Domain.com within the Locations tree).

My research shows everybody mentioning Group Scope as being important here, so I started looking into this. After research and trial/error, I am able to create a new group (domain local) called Parent Domain Admins and add the Domain Admins group from the Parent domain into it. However, I still cannot add this group into the Domain Admins group in Child.

I'm to the point where I don't know what else to try and Google is failing me. How can I accomplish this sort of thing?

How can I manage a domain with the "Active Directory Users and Computers" from a computer that is not on that domain? I realize I'll need some domain admin (or less) credentials, but that's fine.

I have 2 scenarios where I'd like to do this:

1. From a machine on Domain 1 but I'd also like to manage Domain 2 (the 2 domains are in no way related)
2. From a laptop that is not a member of any domain.

If we can figure out #2, that will be "good enough" but #1 would be nice too.

I'm very new to AD LDS and experienced but not qualified with SSAS, so my apologies for my ignorances with these.

We have a couple implementations where we expose SSAS via an HTTPS proxy (msmdpump.dll) and currently we have a temporary domain setup handling this (where our end-users have a second account+creds to manage because of this = non-ideal). I want to move us towards a more permanent solution which I'm thinking of moving all authentication to AD LDS for our web apps, SSAS, and others. However, SSAS is where I'm concerned about this.

I know SSAS requires Windows Authentication and to play nicely, and that this ultimately means Active Directory will be involved.

Is there a way to get this done with AD LDS instead of having to use a full AD DS implementation? If so, how?

(Note: My question over at StackOverflow had a suggestion that I post this question here on ServerFault instead. My apologies if I'm not asking in the right forum.)