Wifi – Deploying Windows via SCCM 2012 OSD Wireless

Try this (on the client computer):

1. Login locally using a user with administrator privileges.

2. Connect to your office's wireless network, save the credentials, and then make sure you check the "Connect automatically" checkbox.

3. Open a command prompt window and type the following command to find the profile name of your wireless network: netsh wlan show profiles

   

4. Let's say the profile to use in the example is "office-network". Open regedit and look for the key HKLM\Software\Microsoft\Windows\CurrentVersion\Run

5. Create a new String Value (REG_SZ) at that location, and name it anything you want (i.e. WIFI_Connect), and enter the following command string: %comspec% /c netsh wlan connect name="<profile name>" where profile name in our example would be "office-network".

6. Reboot the laptop for this to take effect.

7. If it still doesn't work or fails to connect to your office network at pre-logon, try enabling the following Local Group Policy (using gpedit.msc): Computer Configuration\Policies\Administrative templates\System\Logon\Always wait for the network at computer startup and logon. A full description of what this policy does is present on the dialog when you edit it. (It's too long to paste here).

8. If it still says it cannot find a valid domain, it could be a DNS issue. Make sure that the wireless router providing you the connection is setup to provide the proper DNS servers over DHCP, and that the domain can be resolved with them.

If not of that works, I don't know what is wrong, but it's nothing obvious. Every KB I've read so far point to this solution, and it seems to work well for others.

First of all, let me say that you (well, your bosses, maybe) really need to get off of using a domain you don't own. You say it's too big to do that now, but you're being short-sighted. If it's "too big" to change now, what happens in the future, when it's even bigger? You're just letting the problem grow and grow, until (if the company actually does succeed and continue to grow) you'll end up with a problem which really will be "too big" to handle, and you'll spend fantastic amounts of money and time and create a lot of user-impact to correct what you probably could correct now for much less effort. At the very least, you should see if you can buy the domain your AD is using from its current owner, which would be the quickest way to correct this.

Anyway, having said, and assuming your bosses aren't willing to actually be reasonable, smart, or think further into the future than their next bonus check, there actually is a pretty east way around this, which you mentioned in your question.

What you would want to do is:

1. Create a second child domain in your Active Directory forest.
   • Pick a domain you own this time, or buy whatever domain you pick, for the love of God.
2. Create a trust between the new domain and the old one (within AD).
3. Create appropriate user groups, resources and permissions in new domain.
   • Setup a RADIUS/NPS server here that's got permissions to authenticate against the old domain, or perhaps just your RADIUS-capable devices, and allow them to authenticate against the old domain (or however you want to do it).
4. Manage permissions in old domain so that users of new domain have required access.
   • For example, make sure that any SSL cert you purchase for this domain will be accepted by the old domain, if that's the route you go.
5. (OPTIONAL, but HIGHLY RECOMMENDED) Use the new child domain to migrate away from the old one you don't actually own
   • Once the trusts are established and working, you can use them to migrate users off of the old domain you don't own, onto something you do, and make the problem go away eventually.
     • I am actually in the middle of a Windows Active Directory domain migration, and this is how we're handling it too.
     • We've created a second child domain, established trusts, and slowly started migrating users, services, machines (everything) over to the new domain, so the old, broken domain will eventually be empty and unused, at which point we'll dispose of it.