Windows 7 Sharing Fix

There is nothing quite so humbling as bashing your head against a workstation for hours trying to figure out why the damn thing won't access a simple network share. Sure, there are a lot of specifics to the problem, but all the same... anyway, here's what I was up against:

- Two fresh windows 7 installations, all the latest updates (as of 2/23/2010)
- Workgroup machines, not in the same workgroup
- One has a Everyone share, with restricted NTFS permissions
- Neither machine can access eachother's c$ or admin$ shares

I am not sure which of the following steps fixed it... but I did all of them, and it's working now... so take that for what it is worth:

click the start button and type secpol.msc in the search function.

Browse to "Local Policies" -> "Security Options". Now look for the entry "Network Security: LAN Manager authentication level" and open it. Click on the dropdown menu and select "Send LM & NTLM - use NTLMv2 session security if negotiated". Apply the settings.

In the Advanced sharing settings page of Network and sharing center, you need to have it set as Work/Home profile. Try

-Enable network discovery
-Turn on file and print sharing
-Turn off password protected sharing
-Use user accounts and passwords to connect to other computers

The other settings such as encryption I have set as use 128 bit encryption.

Please check related policies.

1. Enter “gpedit.msc” in the Start Search box.
2. Open “Computer Configuration”/Windows Settings/Security Settings/Local Policies/Security Settings.
3. In the right pane, enable the following policies:

Network access: Allow anonymous SID/name translation
Network access: Let Everyone permissions apply to anonymous users

Also please disable the following policies.

Network access: Restrict anonymous access to Named Pipes and Shares
Network access: Do not allow anonymous enumeration of SAM accounts
Network access: Do not allow anonymous enumeration of SAM accounts and shares

Now, go into the control panel and search for homegroup. Click "Choose homegroup and sharing options" and remove yourself from any groups.

Reboot both machines.

Now, when you attempt to access a admin share, you should get a login box. Enter a username and password of an account present on the other machine, and you should get in.

Worth noting: if you attempt to browse to a share like \\workstation\share and double click on it, you may just get access denied. This is because Windows 7 is trying to use its local credentials to log into the share and failing. If you then attempt to log into an admin share, you will get a different error about connecting to one resource with more than one name.

Open a command prompt and type net use * /delete to remove all network connection sessions that are cached... then try to open the admin share by going to \\workstation\c$. It will ask you for a username and password, and that should work.

You can also create a mapped drive, and check the box telling Windows 7 you want to use different credentials. When you create the drive, it will ask for a username and password. Check the box to remember the password, then enter the local user name of an account on the machine which is sharing the folder you want to access (no domain or computer name in front of it... just username). Voila!

Publishing Autodiscover through ISA

This post is based more on personal experience rather than researched fact... just a heads up. May or may not work in other environments, but it was a troublesome enough discovery process that I thought it was worth sharing. The problem was that I had an ISA 2006 box publishing my Exchange 2007 access methods (OWA, RPC/HTTPS, Autodiscover, etc). And everything was working fine, except for Autodiscover. The Autodiscover process would hang while trying to get its settings through the ISA server, then give up. In the ISA logs, I could see that the requests to autodiscover.domain.com were getting rejected because they required authorization.

Here's some additional background on my environment setup:
- ISA 2006 is configured with Authentication to my internal LDAP (Active Directory) servers
- The rule publishing my Outlook Anywhere services was configured for Authenticated Users only. It included the /Autodiscover site as one of its sites to allow traffic for.
- I was using a SAN SSL certificate (from godaddy) with webmail.domain.com as its principal name, and autodiscover.domain.com as one of the SAN names.

I'll cut to the chase and explain what I did and why. I had to remove /Autodiscover from the list of accepted sites on my default Outlook Anywhere rule, then create a new rule just for Autodiscover. The new rule featured the following differences from the original rule:
- On the "To:" tab, I still had the principal name of the certificate... webmail.pih.net. However, in the "Public Name" tab I specified "autodiscover.domain.com" as the only Website/IP.
- On the Paths tab I left the default path of "/*"... you could also specify /Autodiscover, but I didn't care to.
- On the Users tab, I had to remove "Authenticated Users" and add in "All Users". This was the real trick that got autodiscover working, I think.
- I put the rule lower on the list than the rest of the rules for good measure.

Once this change was applied, Autodiscover worked like a charm. No more ISA logs barking about denied connections (still got a few failed connections, the usual error 64 and 10054 stuff... thats normal for an RPC/HTTPS connection mind you...), and autodiscover goodness all around. I noticed that now Autodiscover pops up a box asking for login credentials during its discovery process (even though I specified the same credentials already during configuration of the outlook profile), but this is a small price to pay for working Autodiscover.

I later verified this configuration with Microsoft, by the way... an ISA engineer to be specific. He did not explain why this was, but indicated it may be an Outlook Client problem... its not responding to the request from ISA to authenticate... so the rule allowed the outlook client to bypass authentication on the ISA server and authenticate directly against the exchange server instead. A slight security breach, but nothing to be terribly concerned about considering its just for Autodiscover.

Exchange Edge Server and DNS

Here's a lesson in items that should (and did) work together, but got hot fixed (pronounced hot-broken) inexplicably. Exchange EdgeSync service (which runs on your Edge server and connects to your CAS server for LDAPs information) relies on ports 50389 (internal to the box - it connects to itself) and 50636 (external, from EDGE to CAS). In a recent hotfix (KB951746) by micrsoft, DNS was also changed to reserve 2,500 random UDP ports on startup. It just so happens that the range of ports includes those of LDAP and LDAPs... you can see where this is going.

The symptoms of this problem are that

A) Your EdgeSync service will not start up, because your Exchange ADAM service will not start up.

B) You get an error in the application event log stating something to the effect of "An attempt was made to access a socket in a way forbidden by its access permissions" from the Service Control Manager service (EventID 7023).

C) No incoming email.

The fixes for this on Server 2003/2008 are as follows:

1) Open Regedit on your EDGE server and drill down to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

2) Create a new MultiString Value named "ReservedPorts"

3) In the Value box, enter 50389-50389 on one line, and 50636-50636 on another line. You could also just add 50389-50636 if you are lazy (like me).

4) Restart the server.

Voila, problem fixed.

There is an alternative on 2008 servers as well... you can simply change the "DNS Server" Service to a "Delayed Start (Automatic)" status. EDGESync ADAM should grab its ports before the DNS server does, and all proceeds merrily. There's yet another fix you can do for 2008 R2, but I won't even bother as Microsoft does not even support Exchange 2007 on 2008 R2 as of this writing... so why would you do it? :P