As Christian K instructed, have all internal computers use Stonewall as their DNS server. They should have no knowledge of any DNS servers beyond their LAN.
Stonewall should have itself as its DNS server, but should have the comcast DNS servers as forwarders. So under forwarders in the Stonewall DNS setup, the 2 comcast dns servers (68.105.28.12 and 68.105.29.12) should be the forwarders for "All other DNS domains".
Wednesday, June 4, 2008
Monday, April 14, 2008
Bridge groups and BVIs - slippery concepts
Bridge groups and BVIs are very hard for me to understand. There is no good explanation of these concepts on the web that I am able to find.
As far as I can tell, a bridge group is a logical device to hook (to bridge) a vlan to a wireless LAN. To connect the two, you put a vlan (say vlan 10) into bridge group 7 and then you put the radio interface of a wireless LAN into the same bridge group 7. The result of this is that the computers which communicate with the switch wirelessly are now part of (bridged to) vlan 10. You might consider a wireless LAN to be a vlan even though it never seems to be called a vlan. So when you bridge a wireless LAN and a vlan, you are building a layer 2 bridge between 2 vlans.
A BVI is apparently a way to assign an IP address to this new hybrid (wired and wireless) vlan 10. I guess to get out to the Internet from a computer that is communicating wirelessly to a switch, you have to have both the bridge group and the BVI.
If you don't hook the wireless computers to vlan 10 using the bridge group, then you won't have communication between the wired and wireless computers. And if you don't have the BVI, then there is no way to get out to the Internet because you won't have an IP address.
Back to bridge groups. Let's say you have Wanda using a computer connected wirelessly to a switch and Bob using a computer connected to the switch by cat 5 cable. If you do not combine Wanda's wireless LAN with Bob's vlan, then assume Wanda and Bob cannot communicate. Meaning that they can't ping each other. I assume after you put them both into a common bridge group that they CAN ping each other. I will have to try that experiment some time.
The following 3 commands are necessary, but I don't really understand them. irb is integrated routing and bridging. I guess "bridge 7 route ip" means that IP packets can be routed to bridge group 7.
bridge irb
bridge 7 protocol ieee
bridge 7 route ip
interface vlan 10
bridge-group 7
interface dot11radio0
bridge-group 7
interface BVI7
ip address 192.168.0.1
As far as I can tell, a bridge group is a logical device to hook (to bridge) a vlan to a wireless LAN. To connect the two, you put a vlan (say vlan 10) into bridge group 7 and then you put the radio interface of a wireless LAN into the same bridge group 7. The result of this is that the computers which communicate with the switch wirelessly are now part of (bridged to) vlan 10. You might consider a wireless LAN to be a vlan even though it never seems to be called a vlan. So when you bridge a wireless LAN and a vlan, you are building a layer 2 bridge between 2 vlans.
A BVI is apparently a way to assign an IP address to this new hybrid (wired and wireless) vlan 10. I guess to get out to the Internet from a computer that is communicating wirelessly to a switch, you have to have both the bridge group and the BVI.
If you don't hook the wireless computers to vlan 10 using the bridge group, then you won't have communication between the wired and wireless computers. And if you don't have the BVI, then there is no way to get out to the Internet because you won't have an IP address.
Back to bridge groups. Let's say you have Wanda using a computer connected wirelessly to a switch and Bob using a computer connected to the switch by cat 5 cable. If you do not combine Wanda's wireless LAN with Bob's vlan, then assume Wanda and Bob cannot communicate. Meaning that they can't ping each other. I assume after you put them both into a common bridge group that they CAN ping each other. I will have to try that experiment some time.
The following 3 commands are necessary, but I don't really understand them. irb is integrated routing and bridging. I guess "bridge 7 route ip" means that IP packets can be routed to bridge group 7.
bridge irb
bridge 7 protocol ieee
bridge 7 route ip
interface vlan 10
bridge-group 7
interface dot11radio0
bridge-group 7
interface BVI7
ip address 192.168.0.1
Friday, March 28, 2008
Redirecting My Documents with Group Policy
A user's My Documents folder can be redirected to a folder on a server using the group policy below:
User config - > Windows settings-> Folder redirection
Once you've gotten to "folder redirection" in the group policy editor by using the path shown above, right click on the My Documents folder underneath the Folder Redirection folder and choose properties. From there you can set where the My Docs folder will be redirected to. There are 4 choices:
1 - Redirect to user's home directory - I'm not sure exactly how home directories work, but if a user has one, this points the user's My Docs at his home folder. According to Microsoft Technet, home directories are not considered the way to go anymore. This option lets you point My Docs at a home directory for companies whose users are already used to using home directories.
2 - Create folder for each user under the root path - this is generally the option that you want to use. It lets you set a root path - say \\Stonewall\users, and then Windows gp will create a folder for each user (using their login name) and put the user's My Docs folder under their named folder. Example:
\\stonewall\users\tayloen\My Documents
\\stonewall\users\samh\My Documents
\\stonewall\users\davidc\My Documents
From Microsoft Technet:
Rather than having to enter a UNC path such as \\server\share\%username%\MyDocuments, the administrator can simply type in the path to the share such as \\server\share, and Folder Redirection will automatically append the user name and the folder name when the policy is applied. This removes the need for administrators to be familiar with environment variables, and minimizes the chances of errors and spelling mistakes.
3 - Redirect to the following location. This option is similar to option 2, but you have to use the old Windows server 2000 interface. In other words, you have to specify the path using the %username% variable:
\\stonewall\users\%username%\My Documents
4 - Redirect to the local user profile - use this to basically undo a previous redirection of a user's My Docs folder. In other words, if after having redirected a user's My Docs folder to somewhere on the server you decide that you want his My Docs to point back at his local computer (like it was before), then use this option. Simply disabling the "Folder Redirection" group policy will NOT return the user's My Docs to his local computer. This setting will.
The other choice on the My Docs properties window asks you to choose whether you use basic or advanced redirection. Basic is as described above. I think advanced lets you choose a different root path based on group membership. For instance, instead of everybody having their My Docs folder under \\stonewall\users, you could have administrators have theirs under \\stonewall\admins and Engineers under \\stonewall\engineering.
User config - > Windows settings-> Folder redirection
Once you've gotten to "folder redirection" in the group policy editor by using the path shown above, right click on the My Documents folder underneath the Folder Redirection folder and choose properties. From there you can set where the My Docs folder will be redirected to. There are 4 choices:
1 - Redirect to user's home directory - I'm not sure exactly how home directories work, but if a user has one, this points the user's My Docs at his home folder. According to Microsoft Technet, home directories are not considered the way to go anymore. This option lets you point My Docs at a home directory for companies whose users are already used to using home directories.
2 - Create folder for each user under the root path - this is generally the option that you want to use. It lets you set a root path - say \\Stonewall\users, and then Windows gp will create a folder for each user (using their login name) and put the user's My Docs folder under their named folder. Example:
\\stonewall\users\tayloen\My Documents
\\stonewall\users\samh\My Documents
\\stonewall\users\davidc\My Documents
From Microsoft Technet:
Rather than having to enter a UNC path such as \\server\share\%username%\MyDocuments, the administrator can simply type in the path to the share such as \\server\share, and Folder Redirection will automatically append the user name and the folder name when the policy is applied. This removes the need for administrators to be familiar with environment variables, and minimizes the chances of errors and spelling mistakes.
3 - Redirect to the following location. This option is similar to option 2, but you have to use the old Windows server 2000 interface. In other words, you have to specify the path using the %username% variable:
\\stonewall\users\%username%\My Documents
4 - Redirect to the local user profile - use this to basically undo a previous redirection of a user's My Docs folder. In other words, if after having redirected a user's My Docs folder to somewhere on the server you decide that you want his My Docs to point back at his local computer (like it was before), then use this option. Simply disabling the "Folder Redirection" group policy will NOT return the user's My Docs to his local computer. This setting will.
The other choice on the My Docs properties window asks you to choose whether you use basic or advanced redirection. Basic is as described above. I think advanced lets you choose a different root path based on group membership. For instance, instead of everybody having their My Docs folder under \\stonewall\users, you could have administrators have theirs under \\stonewall\admins and Engineers under \\stonewall\engineering.
Sunday, March 23, 2008
Seeing and Changing environmental variables
To see what the current value of an environmental variable is or to change it:
echo %comspec%
echo %PATH% (however, it works even if you don't capitalize it)
Or to do it in the GUI
Go to System Properties by either typing Windows+Break or by right clicking on My Computer and choosing properties.
Once in System Properties, go to the advanced tab and click on the Environmental Variables button.
echo %comspec%
echo %PATH% (however, it works even if you don't capitalize it)
Or to do it in the GUI
Go to System Properties by either typing Windows+Break or by right clicking on My Computer and choosing properties.
Once in System Properties, go to the advanced tab and click on the Environmental Variables button.
Friday, March 21, 2008
Deleting a local user profile
To delete a user's profile (not the user himself, just his profile) from the local computer, go to:
control panel
system applet
advanced tab
user profiles -> settings
Then delete the profile for whichever user you want. The next time the user logs in, the default user profile will be loaded for the user.
control panel
system applet
advanced tab
user profiles -> settings
Then delete the profile for whichever user you want. The next time the user logs in, the default user profile will be loaded for the user.
Thursday, March 20, 2008
Remote Desktop (Hello, Vienna calling....)
As with so many of my posts, this is really just a note to myself to remind me of how to do something that I don't do that often. Then when I need to do it, I fumble around for a half an hour trying to remember how to even get started!! Very embarrassing for a kick-ass network admin...
Remote Desktop - how to be there when you're not there.
If you are sitting in front of your computer and you wish you were sitting in front of another computer, the solution is to access that other computer using remote desktop (formerly known as terminal server client). To start a remote desktop session, go to Start, All Programs, Accessories, Communications, Remote Desktop Connection. You will be asked to enter the name of the remote computer you want to access, and then click "connect". Then you'll see the desktop of the remote computer and a login box. Enter a username and password that are valid on the remote computer and you're in!
By the way, on the Remote computer, you must have previously enabled it to receive a remote desktop visitor. How to do that? Keep reading......
You have to physically go to the remote computer and access to the system properties dialog box. Both of the following ways will get you to the properties box:
1. Press the windows key and the break key at the same time (this is the fast way).
2. Go to Windows Explorer and right click on My Computer. Then choose properties from popup menu.
Once in system properties, choose the remote tab. Then check the checkbox labeled "Allow users to remotely connect to this computer". Don't get confused and check the checkbox labeled
"Allow remote assistance invitations to be sent from this computer".
Remote Desktop - how to be there when you're not there.
If you are sitting in front of your computer and you wish you were sitting in front of another computer, the solution is to access that other computer using remote desktop (formerly known as terminal server client). To start a remote desktop session, go to Start, All Programs, Accessories, Communications, Remote Desktop Connection. You will be asked to enter the name of the remote computer you want to access, and then click "connect". Then you'll see the desktop of the remote computer and a login box. Enter a username and password that are valid on the remote computer and you're in!
By the way, on the Remote computer, you must have previously enabled it to receive a remote desktop visitor. How to do that? Keep reading......
You have to physically go to the remote computer and access to the system properties dialog box. Both of the following ways will get you to the properties box:
1. Press the windows key and the break key at the same time (this is the fast way).
2. Go to Windows Explorer and right click on My Computer. Then choose properties from popup menu.
Once in system properties, choose the remote tab. Then check the checkbox labeled "Allow users to remotely connect to this computer". Don't get confused and check the checkbox labeled
"Allow remote assistance invitations to be sent from this computer".
Tuesday, February 19, 2008
Group Policy can be fun....
Well, I'm heavy into Active Directory Group Policy using a good book by Jeremy Moskowitz as my guide. I'm Learning how to do the "Big Brother" stuff to all the users and computers in an Active Directory domain. The concepts are pretty straightforward, but the devil is in those details.......
Just some notes here to myself.....
You can put an OU inside another OU, but you can't put a group inside another group. This reminds me of the old saying "You can take the girl out of Arkansas, but you can't take the Arkansas out of the girl..."
You can add a computer to a group, but you have to remember to click the "object types" button when you are in the "select things to add" dialog box and then check "computers" so that computers will appear as possible things for you to add to the group.
You can limit the scope of a GPO in two ways:
Way 1 - The first way (and best way it seems to me) is to simply create two groups and apply the GPO only to the group you want to have it. Put everyone you want to get the GPO in the group that you applied the GPO to. Perhaps there are times when this is not practical; this leads us to the second way to limit the GPO scope...
Way 2 - First create the GPO and apply it to "Authenticated Users" which is the default and covers everybody. Then, on the "scope" tab of the GPO, add another group. This second group will be for the people that you DON'T want the GPO applied to. Once you've added that second group, go to the delegations tab of the GPO and then click the "advanced" button. Then scroll down to the group you just added and check the "deny" box under "apply group policy". This works, but it's tricky because when you go back to the scope tab of the GPO, the 2nd group no longer appears because the GPO doesn't apply to it anymore. BUT, it's still affected by the GPO since the GPO is now denied to it. You can still see the group by going to the delegation tab of the GPO and looking at the list of groups. The group will have "custom" under "allowed permissions". Sheeeesh....
Just some notes here to myself.....
You can put an OU inside another OU, but you can't put a group inside another group. This reminds me of the old saying "You can take the girl out of Arkansas, but you can't take the Arkansas out of the girl..."
You can add a computer to a group, but you have to remember to click the "object types" button when you are in the "select things to add" dialog box and then check "computers" so that computers will appear as possible things for you to add to the group.
You can limit the scope of a GPO in two ways:
Way 1 - The first way (and best way it seems to me) is to simply create two groups and apply the GPO only to the group you want to have it. Put everyone you want to get the GPO in the group that you applied the GPO to. Perhaps there are times when this is not practical; this leads us to the second way to limit the GPO scope...
Way 2 - First create the GPO and apply it to "Authenticated Users" which is the default and covers everybody. Then, on the "scope" tab of the GPO, add another group. This second group will be for the people that you DON'T want the GPO applied to. Once you've added that second group, go to the delegations tab of the GPO and then click the "advanced" button. Then scroll down to the group you just added and check the "deny" box under "apply group policy". This works, but it's tricky because when you go back to the scope tab of the GPO, the 2nd group no longer appears because the GPO doesn't apply to it anymore. BUT, it's still affected by the GPO since the GPO is now denied to it. You can still see the group by going to the delegation tab of the GPO and looking at the list of groups. The group will have "custom" under "allowed permissions". Sheeeesh....
Thursday, January 17, 2008
How could anyone be so stupid....
So I'm out here in Vegas now, and I'm trying to learn Active Directory and Group Policy and all that jazz. In my home network setup, I have a Win 2003 server (stonewall) and one Win XP profesh client (jupiter). I have 2 more windows computers, but they have the wretched (but cheaper) Win XP Home installed on them. So they can't receive Group Policy commands from stonewall because Windows Home doesn't play well with domain networks.
I'm pulling my hair out because jupiter won't "submit" to any domain GPO's (group policy objects) that I configure using the GPMC (group policy management console) on stonewall. It used to work, but now it won't. So I post a very professional question on Experts-Exchange.com (HELP!!!! this @#$%$! thing won't work!!!) but don't get any helpful replies. So I pull out the big guns. I post a "job" on Guru.com asking someone to please explain to me why jupiter just laughs at the the group policy commands sent down from stonewall. I get many replies, but the one that catches my eye says (paraphrasing) "99.9 percent of the time when there is a problem getting domain level GPOs to work it turns out to be a dns problem. Make sure that the client has the right address (in this case stonewall's address) for its dns server." What an insulting response, I think. But maybe it wouldn't hurt to just take a sec and check that out.......
Oops. From a quick "ipconfig /all" on jupiter, I see that jupiter is configured to use 2 dns servers neither one of which is stonewall. I immediately realize that jupiter is set to get its dns info from my local dhcp server (my Cisco 871w router) and my Cisco 871w just sends jupiter the 2 dns servers that it got (by dhcp) from Cox Communications, my ISP.
So that's the problem. It's not even a group policy problem, it's a basic network setup problem. I don't know the intricacies of Active Directory/Group Policy (yet) but I at least should know clients are supposed to be getting their dns info from their own Domain Controller......
So the Guru.com guy, who bid about the cheapest dollar price of any of the people who responded, fixed my problem without even bothering to hear the details! Wow. That's fine troubleshooting. The man has obviously seen a lot of mangled networks. Most of which probably had admins as dumb as me......
I'm pulling my hair out because jupiter won't "submit" to any domain GPO's (group policy objects) that I configure using the GPMC (group policy management console) on stonewall. It used to work, but now it won't. So I post a very professional question on Experts-Exchange.com (HELP!!!! this @#$%$! thing won't work!!!) but don't get any helpful replies. So I pull out the big guns. I post a "job" on Guru.com asking someone to please explain to me why jupiter just laughs at the the group policy commands sent down from stonewall. I get many replies, but the one that catches my eye says (paraphrasing) "99.9 percent of the time when there is a problem getting domain level GPOs to work it turns out to be a dns problem. Make sure that the client has the right address (in this case stonewall's address) for its dns server." What an insulting response, I think. But maybe it wouldn't hurt to just take a sec and check that out.......
Oops. From a quick "ipconfig /all" on jupiter, I see that jupiter is configured to use 2 dns servers neither one of which is stonewall. I immediately realize that jupiter is set to get its dns info from my local dhcp server (my Cisco 871w router) and my Cisco 871w just sends jupiter the 2 dns servers that it got (by dhcp) from Cox Communications, my ISP.
So that's the problem. It's not even a group policy problem, it's a basic network setup problem. I don't know the intricacies of Active Directory/Group Policy (yet) but I at least should know clients are supposed to be getting their dns info from their own Domain Controller......
So the Guru.com guy, who bid about the cheapest dollar price of any of the people who responded, fixed my problem without even bothering to hear the details! Wow. That's fine troubleshooting. The man has obviously seen a lot of mangled networks. Most of which probably had admins as dumb as me......
Finding the IP addresses of your DNS servers on Cisco
This is really just a note to myself. As long as I can make it back to this website, I can't lose the note!!!
On my home network, my Cisco 871w router acts as my gateway/firewall/dhcp server. To find out what DNS servers my Cisco 871w router (acting as a dhcp server to computers on my LAN) is sending out by dhcp to clients, do "show hosts". The output looks like:
Name lookup view: Global
Default domain is lv.cox.net
Name/address lookup uses domain service
Name servers are 68.105.x.x, 68.105.x.x
To see what "gateway of last resort" (default gateway) the 871w is using, do "show ip route". Amongst all the other route info, it will show you the gateway IP address.
The way to tell the 871w which dns server to give out to dhcp clients is in the code fragment below, which comes from the config file on the 871w router. The "dns-server" line is the actual line that assigns the dns server.
ip dhcp pool sdm-pool
import all
network 10.10.10.0 255.255.255.0
default-router 10.10.10.1
dns-server 10.10.10.50
lease 10
It seems like there ought to be away for the router to give the dhcp client computers more than one dns server, but I haven't haven't figured out how to do that yet.
On my home network, my Cisco 871w router acts as my gateway/firewall/dhcp server. To find out what DNS servers my Cisco 871w router (acting as a dhcp server to computers on my LAN) is sending out by dhcp to clients, do "show hosts". The output looks like:
Name lookup view: Global
Default domain is lv.cox.net
Name/address lookup uses domain service
Name servers are 68.105.x.x, 68.105.x.x
To see what "gateway of last resort" (default gateway) the 871w is using, do "show ip route". Amongst all the other route info, it will show you the gateway IP address.
The way to tell the 871w which dns server to give out to dhcp clients is in the code fragment below, which comes from the config file on the 871w router. The "dns-server" line is the actual line that assigns the dns server.
ip dhcp pool sdm-pool
import all
network 10.10.10.0 255.255.255.0
default-router 10.10.10.1
dns-server 10.10.10.50
lease 10
It seems like there ought to be away for the router to give the dhcp client computers more than one dns server, but I haven't haven't figured out how to do that yet.
Subscribe to:
Posts (Atom)