I've installed the W7 RC in a virtual machine to test it out. I've joined the AD domain without any problems. When I'm logged in with my domain admin account, everything works as I expect it to. When I'm a normal domain user, there are several issues: When trying to browse shares, I'm asked for credentials. Login scripts aren't run, and my home dir isn't mapped (probably because it can't authenticate). When I try to access Sharepoint, I usually only type the hostname. The Sharepoint server can only be found when I type in the FQDN. When I do get to it, I'm asked for credentials again. When trying to access network shares, I get an authentication popup, and an alert in the system tray. The alert tells me "Windows needs your current credentials. Please lock the computer then unlock it with your most recent password or smart card." This doesn't work. The dialog claims "The system detected an attempt to comprimise security. Please ensure you can contact the server that authenticated you." This does work, but must be done for each server. None of the above happen to my domain admin account. I'm running Vista on the VM host, and none of the above issues occur with it either.

No comments? No-one else has experienced this? In further testing, I've found that Group Policy only gets deployed to Domain Admins as well. Normal users don't get it. I've re-installed twice, and nothing changes. Only Domain Admins can use the machine normally. This problem didn't show up in the Beta. I'm about to back my laptop up and try it on that, but I don't hold out any hope.

We don't support Windows 7 RC in a virtual machine, just when installed clean on a system.

We don't support Windows 7 RC in a virtual machine, just when installed clean on a system. Doesn't work on my laptop either, exactly the same symptoms.

If I can just add my 2 cents. The policy about"clean" machines vsVMs is understandable but misguided.Since MS has started taking pre-orders for Win7, it seems that the policy about handling problems on VM vs. a clean machine should be loosened up. Those of us in the corporate world do lots of testing on VMs as I am pretty sure MS does as well. In my own little cube, I have 5 hardware PCs and 4 VM builds. It is crowded and warm.The point being that VMs are a reality out here and should at least be added to the testing mix. In addition, the items that RitterWolf are concerned with work just fine on my VMs running Win2K andWinXP. We have skipped Vista because of all its costs/problems. If MS wants us to even begin to think of Win7 as an option, it should jump into supporting the way that enterprise IT works. That work is totally dependent on AD working correctly in every case, VM or not. Don't want to seem too grouchy, but a VM is what many of us have to work with. Perhaps, to lessen the complexity, MS could support Win7 RC ononly its own VM?

I'm not seeing this. What happens if you make the users local administrators? Im' not recommending this. It's a troubleshooting step to see if the problem is with the local machine or the domain.Please post the results of ipconfig /allKerry Brown MS-MVP - Windows Desktop Experience

dknapp, I agree with you in principle. I think VMs should be supported in betas though. Testing is so much easier when you can push a button, break something, and then restore everything in less than 5 minutes. Its really neither here nor there in this case, as the beta worked properly, and the RC doesn't. Kerry, Making the user a local admin didn't fix it in VM or on physical. I'll back my laptop up, and install the RC again. Of course, I'm going to be embarrassed if it works now...

I've fixed it. I was being a smartarse, and documenting everything as I went through installation and testing. Tested my user, my admin user, another persons user, and yet another persons user, only to find that the other users worked, without being a Domain Admin. Well, that showed me... The difference? I'd been playing with Kerberos stuff a while back, when I was trying to join a Linux machine to the domain before Likewise Open made it really easy. I screwed around with some Kerberos stuff, attaching it to my user account, causing my account to be a special little flower. setspn -D didn't help, but I noticed that my account had "Use DES encryption types for this account" option turned on, but the working users' didn't. I killed it, and it started working. My guess is that something changed between Beta and RC that stops W7 working properly in a domain environment when DES is enabled on your user account.

That is because DES is disabled by default in Win7 RC and later builds. It is an far less secure cryptographic algorithim designed in the 1970's that is provided solely for non-MS interoperability (MS developershave not beenallowed to use it for years - they must instead use AES256 or stronger). It can be re-enabled as a valid Kerberos crypto type through the registry or group policy. We would rather you updated your applications that still use DES to use something safe instead, though. Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team

Would you please indicate howto re-enabled DES as a valid Kerberos crypto type through the registry? Thanks.

You can and should instead use GP rather than direct registry editing:Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options \ Network security: Configure encryption types allowed for KerberosTo add DES support back in, select all values except 'future encryption types'. Do not simply select the two DES options, or you will be disabling AES/RC4 and your logons will fail against Windows KDC's.The registry value uses a bitwise maskand should not be manually edited.Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team