2

Good day everyone, I'm in the midst of testing out Windows 8.1 as an enterprise OS to avoid a crisis when Win7 is no longer supported. One of the problems I've run into is with drive mappings. Most of them are working just fine, but we use one that maps to a user specific folder, sort of like their home drive.

In WinXP and Win7 it worked fine, we just mapped the drive to \share\folder\%username% and it was golden, that same GPP drive map in Win8.1 just maps to \share\folder. The name of the folder comes up correct, which also just uses %username% so I'm having trouble finding the disconnect. When I do a Get-GPResultantSetOfPolicy I can see that there is a 'AD / SYSVOL version mismatch' so, maybe I just need to update my templates, but I'm pretty sure that we updated to the WS 2012 adm/admx. DC are on WS2k8 R2.

I'd read on this blog that %LogonUser% might be the correct way to do this, as when GPOs are processed as 'Administrator' then that is where the drive mapping wants to point. Anyone have any experience with this?

I also read on Group Policy Central about the 'Set users home folder' GPO, but I don't have that template.

mortenya
  • 321
  • 1
  • 8
  • 1
    Not that it's a bad question, but you're planning too far ahead. The end of extended support (meaning free security patches) is currently slated for October 30th, 2020. Planning for something that's almost 7 years out in this industry... is a total waste of time, at best. By the time you even need to start thinking about migrating/upgrading to stay supported, Windows 9 will be old news... which makes planning an upgrade to Windows 8 seem all the sillier. **If** you elect to go to Windows 8, instead of 9, it will be at least a service pack or two more mature by the time you do. – HopelessN00b Jan 27 '14 at 18:38
  • In addition, what type of crisis do you envision? The product will continue to work when mainstream and extended support expires. – joeqwerty Jan 27 '14 at 18:41
  • Well, retail support for Windows 7 will be gone long before extended support is. What we don't want, is to be downgrading Win8+ workstations to Win7 in 5 years, and then be faced with the end of patch support. I suppose that 'crisis' was a poor choice of words, I'm just testing viability of Windows 8.1 so that when OEM Windows 7 is no longer available, we can use Windows 8.1. – mortenya Jan 27 '14 at 18:46
  • 2
    An "AD / SYSVOL version mismatch" doesn't mean that something is wrong with your Administrative Templates. It means that the version number in the GPT.INI file inside the GPO's directory of the SYSVOL doesn't match the version number on the corresponding gPO object in Active Directory. – Evan Anderson Jan 27 '14 at 18:49
  • @mortenya Well, that's a wee bit different, but I wouldn't worry too much about it. The way the OEMs are still pushing 7 over 8 or 8.1, it's likely that MS will have to extend the end of OEM sales out at least once before they end it. Having said that, I guess I could use this as an excuse to spin up a Windows 8.1 template and play around myself... though, it sounds like the problem is what EvanAnderson pointed out, and not anything with Windows 8. – HopelessN00b Jan 27 '14 at 18:53
  • Yes, I didn't think that the version mismatch was likely the culprit, I was just listing that out as something I'd found as I was digging. We will stick with Windows 7 while it is being sold, the reason for evaluating 8/8.1 is so that we're up to date, and if I find the Windows 8.1 isn't going to work on our network for general users, that's fine, we just want to know. – mortenya Jan 27 '14 at 19:00

2 Answers2

2

February Update Rollup seems to have fixed the issue.

mortenya
  • 321
  • 1
  • 8
1

Well, after looking around more, this Microsoft KB article describes exactly my problem. Only issue now is that I'm on Windows 8.1, and this fix is only for Windows 8...

So, a known issue in Windows 8 gets a hotfix, but the issue is still present in Windows 8.1, but there is not 8.1 hotfix.

mortenya
  • 321
  • 1
  • 8
  • So, your users have "Administrator" rights locally? – Evan Anderson Jan 29 '14 at 17:37
  • Actually yes, yes they do. – mortenya Jan 29 '14 at 17:49
  • 1
    I bet it works fine for users w/o local "Administrator" rights. – Evan Anderson Jan 29 '14 at 18:46
  • You're right, if I log in with my non-admin test account, it maps correctly. I was hoping the "Run in logged-on user's security context (user policy option)" would get me past that. Is there a way around this issue, I can't exactly remove local admin rights for the users. – mortenya Jan 29 '14 at 19:37
  • 1
    Perhaps you should consider implementing early 2000's security best practices and stop giving users local Administrator rights. It looks like you've be having better luck w/ the product and, I daresay, a lot of other things, too. – Evan Anderson Jan 29 '14 at 20:39
  • I wish it could be that simple, but layer 8 and a number of proprietary apps mean that we can't remove local admin privileges. At least under the new structure, users are limited to having admin access only in their own department, which is a step up from having Domain Users in the BUILTIN\Administrators group. – mortenya Jan 29 '14 at 21:11
  • I have yet to find an application that truly requires Administrator rights. Granted, I've had to deploy AppCompat shims with some of the more difficult ones, and set lots of permissions that I'd rather not on folders that I'd rather not (subfolders of "Program Files", with explicit permissions specified on EXEs and DLLs below them). Having said that, Microsoft is assuming, more and more, that you're using limited users. Your life is going to get harder moving forward. That doesn't even get into the security nightmare that you're creating if those users have Internet access. Yikes! – Evan Anderson Jan 29 '14 at 21:35