Woops

I forgot I even had this blog...

Android devices not showing in Windows (MTP)

This has bugged me for a few generations of devices now and stumped me a few times...

Nexus 4, HTC One and Nexus 6 that I recall have had similar quirks - especially with later Windows versions (i.e. 8 and later)!

I've moved files off my Nexus 6 a few times since I got it late last year, and this time... it decides to not appear - but I could see it in device manager as an ADB device...

Found this article which explains a simple fix:

http://www.howtogeek.com/195607/how-to-get-your-android-device-to-show-up-in-file-explorer-if-it-isnt/

Basically device manager > Android ADB device > update driver > let me choose > USB MTP device > fixed

Sites, Services and Domain Controllers

One of the things that baffles me is how little Sites and Services is understood and oddly implemented around the place.

I'd recommend giving this a good thorough read through, twice, if you administer AD anywhere - it's one of my most frequently shared links when someone starts talking to me for a couple of reasons of which I'll include a brief summery below...

Sites, Sites, Everywhere... http://blogs.technet.com/b/askds/archive/2011/04/29/sites-sites-everywhere.aspx

1) Automatic Site Coverage

Every domain controller in the forest follows this procedure:

1. Build a list of target sites — sites that have no domain controllers for this domain (the domain of the current domain controller).
2. Build a list of candidate sites — sites that have domain controllers for this domain.
3. For every target site, follow these steps:

1. Build a list of candidate sites of which this domain is a member. (If none, do nothing.)
2. Of these, build a list of sites that have the lowest site link cost to the target site. (If none, do nothing.)
3. If more than one, break ties (reduce this list to one candidate site) by choosing the site with the largest number of domain controllers.
4. If more than one, break ties by choosing the site that is first alphabetically.
5. Register target-site-specific SRV records for the domain controllers for this domain in the selected site.

2) DCLocator

1. Client does a DNS search for DC’s in _LDAP._TCP.dc._msdcs.domainname
2. DNS server returns list of DC’s.
3. Client sends an LDAP ping to a DC asking for the site it is in based on the clients IP address (IP address ONLY! The client’s subnet is NOT known to the DC).
4. DC returns…
   a. The client’s site or the site that’s associated with the subnet that most matches the client’s IP (determined by comparing just the client’s IP to the subnet-to-site table Netlogon builds at startup).
   b. The site that the current domain controller is in.
   c. A flag (DSClosestFlag=0 or 1) that indicates if the current DC is in the site closest to the client.
5. The client decides whether to use the current DC or to look for a closer option.
   a. Client uses the current DC if it’s in the client’s site or in the site closest to the client as indicated by DSClosestFlag reported by the DC.
   b. If DSClosestFlag indicates the current DC is not the closest, the client does a site specific DNS query to: _LDAP._TCP.sitename._sites.domainname (_LDAP or whatever service you happen to be looking for) and uses a returned domain controller.

3) DNS
The information above DCLocator about DNS records

After understanding all this - designing and spotting potential issues may becomes easier...

RODC Deployed and not authenticating local users

I've seen this a few times so I am going to quickly write something about it.
Scenario:
Read Only Domain Controllers (RODCs) are deployed and yet the users that you would expect to authenticate to it, are going to a different domain controller (a normal DC).

Question:
Have you configured Password Replication Policy on the RODC?
Without configuring this they are not doing a lot... (apart from DNS etc. obviously)

I have seen this a few times where someone has deployed an RODC and not followed through the configuration - generally because they understand the concept but not how to put it into practice.



To check the config - go to the DC in Active Directory Users and Computers > Properties > Password Replication Policy

The standard groups are shown and I'd hope a custom one set to "allow"
Standard Groups:
Account Operators - Deny
Administrators - Deny
Allowed RODC Password Replication Group - Allow
Backup Operators - Deny
Denied RODC Password Replication Group - Deny
Server Operators - Deny

Basically, by default - there's nothing allowed!

One of the points of an RODC is that it limits what is hit if its stolen.

If you add authenticated users in there –great, it’ll cache everyone's passwords locally (apart from those denied)  If its stolen you've lost the lot… there’s an option when removing an RODC (by force) that says “do you want to force reset all the cached passwords”

That’d cause massive headaches for those users if authenticated users is in there as every single account would be prompted to change password, and if you have a stray service account in there. uhoh.

Allowed RODC Password Replication Group by default contains nothing… you can populate this, but you will distribute this around all RODCs - this may not be desirable.

I created an admin group in there for delegated RODC admins only, as they may be done by a single infrastructure team (using nested groups).

Then separated each RODC with its own custom resource group, in which there were computer groups and user groups for users/computers and servers.

In the password delegation tab on the RODC:

RG-RODC-Cache

in the RG-RODC-Cache group:

UG-RODC_Cache-Users

CG-RODC_Cache-Workstations

CG-RODC_Cache-Servers

Any users/workstations/servers added to the above groups (split up for ease of delegation between users/servers as may be done by different teams) will be able to authenticate to the RODC as their password is cached. Any others will go to the RW DCs.

Some screenshots would be useful here, but I don't have time to add them at the moment - I may come back and add them later.

Powershell - get domain from distinguishedname

Had problems finding this little nugget of Powershell before...

So I am noting this down here for simplicity when I come to need it again...

$dn = "cn=name,ou=oulocation,dc=domain,dc=local"

$domain = $dn -Split "," | ? {$_ -like "DC=*"}
$domain = $domain -join "." -replace ("DC=", "")
Write-Host $domain

The above is setting an example $dn but will probably be grabbed by another bit of code elsewhere...

then split the DN on , and only get the bits that start DC=something
then join the output together with a . in between, then get rid of DC= that lingers behind so you end up with: domain.local

Hope this helps other people out there with a similar query!

Motorola Xoom Jellybean 4.1.2 OTA (WiFi)

The latest OTA for the Motorola Xoom GED is here: http://android.clients.google.com/packages/ota/motorola_tervigon/75baa1719d30.signed-tervigon-JZO54K-from-JRO03H.75baa171.zip

Minus seems to have blocked uploads from non-image files so I can't post a minus mirror sadly.

It applies via OTG cable with stock recovery too as per honeycomb OTAs

Flashing the Xoom JB OTA

If you get an error manually flashing the Xoom JB OTA for GED WiFi then a solution has been found if you don't want to wait...

Note: This article assumes you have basic knowledge of fastboot and/or have already unlocked.

1. Download OTA and custom recovery

- OTA : http://android.clients.google.com/packages/data/ota/motorola_tervigon/f85d815e2b75.signed-tervigon-JRO03H-from-IMM76.f85d815e.zip

- Custom Recovery : http://forum.xda-developers.com/showthread.php?t=1604014  Mirror : http://minus.com/lbv0kMHgdyAHRk

2. Unlock the bootloader (For more info look here: http://developer.motorola.com/products/software/)

- Turn off device

- Connect to laptop using USB cable

- Turn on and when the Motorola splash screen comes up press vol-down till you see FASTBOOT

- Run this command from pc/laptop:

- fastboot oem unlock

3. Flash custom recovery

- Boot into bootloader again with FASTBOOT displayed

- flash custom recovery using the following command from:

- fastboot flash recovery eos-recovery-r6.img

4. Install OTA

- Enter Recovery by powering on, press vol-down till RECOVERY is shown and then press vol-up to enter recovery

- You may need to press power+vol up to enter recovery * if you still appear to have stock repeat step 3.

- Select through the recovery menus, and find 'install from sdcard'

- Select the OTA .zip file from the sdcard and install.

- Reboot device

- Alternatively with the custom recovery you can store the OTA .zip  file on the internal storage on the Xoom and flash it that way without an sdcard or USB with OTG cable.

Custom recovery will be returned to stock on boot up.