[dubsdj]

Has anybody come across a problem with domain enabled windows 8 tablets when working out of the office.
I have found that the user can only install "APPS" when they are physically in the office building... when they go home and log in, they are able to log in with cached credentials and can run apps etc (Except skype for some weird reason)


BUT..

but the main problem when they are at home is that they cannot install any APPS it just fails every time. They can go to the app store and download an app it says installing but then bombs out with a failure!
My guess is that it's trying to find something on the domain... Which is a serious flaw if this is the case! How can people work outside of the office on a domain tablet ?? That would be stupid!

I don't really know how to get around this. I tried creating a local user for home use but that doesn't work as Apps are per user (Which is causing some real headaches I'm sure)
I also tried to make that domain user a local administrator of the tablet... That doesn't work either.

a bit stuck on this one...

This post has been edited by dubsdj: 04 December 2012 - 10:37 AM

[Tripredacus]

It should be worth noting this thread for reference:
http://www.msfn.org/...ptions-live-id/

It would be interesting to see what the errors are, also if you can find any helpful Event logs relating to the errors. Also (in case it might matter) what is the functional level of the domain?

[dubsdj]

Yes it's running at 2008r2 functional level.

as I said on the domain it's fine, no problem

it's when they are logged in offline which is where the problem appears to be.

[Tripredacus]

dubsdj, on 06 December 2012 - 05:59 AM, said:

Yes it's running at 2008r2 functional level.

I can test using a stock 2008 functional level (never saw a need for the R2 myself) domain I have here and see if I can recreate. I will be using Windows 8 Pro x64...

Order of operations in the spoiler...

Spoiler

Windows 8 Pro x64

- connected to isolated network
- deploy OS
- Go through OOBE, create local user.
- Activate Windows
- Join PC to 2008 Domain.
- Add User (Limited) to AD for testing.
- Create Live Account.
- Sign out of local account

- Connect to internet network
- Sign in with Live Account.
- Open Store
- Sign out with Live Account.

- connect to isolated network
- Sign in with Domain account
- Sign out with Domain account

- connect to internet network
- Sign in with Domain account
- Open Store
- Search top free, pick one (Accuweather)
- Click Install, sign in with Live Account.
- Download and install complete. App works.

Using this procedure I am unable to replicate the expected behaviour. Let me know if I did something incorrectly. Note, my testing domain doesn't have any GPOs set on it as it is only used for imaging via WDS.

This post has been edited by Tripredacus: 06 December 2012 - 11:18 AM

[dubsdj]

I have figured out the problem.

Because I have a mixed environment of XP, Windows 7 and Windows 8 computers I have had to perform profile separation because Windows 7 and windows 8 profiles are actually different. Even though they have the .v2 they are not the same.

The Windows 8 computers are in an OU with loopback processing enabled. In the group policy they are instructed to go to a different location for their profile which overrides the user profile location in Active Directory.
it was the only way to my knowledge that I could mix the different operating systems so that people could roam around and log into which ever pc they want to while maintaining their personal settings.

so this explains why when a user logs in (When not connected to the domain) it is still forcing the profile to look in the location of the server which doesn't exist. This would explain why apps won't install as that's profile specific.

The brainwave came when I noticed that I couldn't create a working local user unless I had removed the computer from the domain because the domain loopback policy is trying to force the user profile to be looking at the server.

might make sense to some people...

So basically the only way to allow users to install stuff at home is to give them a local account to use because I can't fiddle the group policy to know if they are offline and forget the profile redirection.

all of this wouldn't be a problem if I didn't have both windows 7 and windows 8 pc's on the same network.

Now if Microsoft would have put their thinking hat on and said ok lets call Windows 8 profiles .V3 then we wouldn't be having this problem!

In all seriousness I think others might get tripped up on this.... I can't imagine I'm the only one trying to mix different OS's in a domain with roaming users.

This post has been edited by dubsdj: 07 December 2012 - 05:24 AM

[jaclaz]

Good to know you found the solution to your issue .

dubsdj, on 07 December 2012 - 05:02 AM, said:

Now if Microsoft would have put their thinking hat on and said ok lets call Windows 8 profiles .V3 then we wouldn't be having this problem!

In all seriousness I think others might get tripped up on this.... I can't imagine I'm the only one trying to mix different OS's in a domain with roaming users.

You see, that would be highly logical and consequent IF you assume that MS wants Corporate IT to have BOTH Windows 7 and 8.
IF the scope is to kill for good Windows 7 and push the stupid 8, then making the co-existence "easy" starts appearing a lot like ILlogical.
And no, in both cases, it is NOT fascinating .

Spoiler

jaclaz

[Tripredacus]

jaclaz, on 07 December 2012 - 07:59 AM, said:

You see, that would be highly logical and consequent IF you assume that MS wants Corporate IT to have BOTH Windows 7 and 8.

I have a sneaking suspicion that the official answer would be "You won't have this problem with Server 2012..."

[jaclaz]

Tripredacus, on 07 December 2012 - 09:17 AM, said:

I have a sneaking suspicion that the official answer would be "You won't have this problem with Server 2012..."

Which could open the way to void the old approach to "lifetime" software licenses and inaugurate the new Saas (Software as a service) era, you will pay a yearly fee and it will be our pleasure to make sure that some new senseless changes to file formats and protocols will be issued periodically, in order to make the life of those still making use of the old paradigm so tough that they will beg us to be allowed to shift to the new model (and pay dearly for it).

Of course, in due time, and as soon as the large majority of customers will have shifted to the Saas, we will be able to stop making those changes, fire quite a few of the programmers we now pay to make the senseless changes, and earn even more money.

The guys who invented planned obsolescence were kids compared to us.....

jaclaz

This post has been edited by jaclaz: 07 December 2012 - 11:01 AM

[dubsdj]

I was looking at Server 2012, the upgrade process looks quite easy from R2.

[Tripredacus]

dubsdj, on 08 December 2012 - 01:09 PM, said:

I was looking at Server 2012, the upgrade process looks quite easy from R2.

Server 2012 is basically the same as 2008 R2. Just make sure you choose to install the Desktop Experience if you are used to using the GUI in 2008 R2 and previous versions of Server.

[dubsdj]

haha

yes good idea