_Adam_

A quick search found this website which looks the cleanest way: My vision on future workplace and datacenter: Default program opening file on RDS/TS The more complicated way is to update the registry key under HKLM.

The 4100 series switches from a quick scan of their manuals seem to be edge switches, not core. I may be incorrect here, but routing does not seem to be a strong point which any core needs. Hence the forward-protocol commands I gave you will not work as you found. When switches do not support PXE across VLANs, then you may need to revert back to DHCP options (minimum options 3, 6, 66, 67). I am not familiar with the Juniper device at all, so TheScarfedOne may have better advice here. If you're seeing the gateway IP of the 192.168.0/22 to 192.168.0.72, then I think the route command needs to be ip route 192.168.0.0 255.255.252.0 192.168.0.72.

The simplistic answer is ADR and NAP do not work well together, unless you manually catch new updates and apply NAP Evaluations to them, or design a script to do this. Going to scrap the ADR configs and revert to static update groups which is less admin.

Is there a route between 192.168.68.x and 192.168.0.x? If so, add the following commands to the 192.168.68.x vlan: ip forward-protocol udp 192.168.0.12 tftp ip forward-protocol udp 192.168.0.12 4011 I have not tried this directly with WDS, but with SCCM which manages WDS.

We have successfully been running NAP now using NPS and WSUS for some years. To consolidate and treat SCCM as a one stop shop we have brought WSUS under its roof. By association this means NAP will also be controlled via SCCM. Enabling NAP on updates is straight forward enough, but does anyone have any experience with ADR groups and NAP? When a new critical update is automatically deployed I suspect it does not get the NAP Evaluation enabled and therefore not get checked. Do we need to revert back to static update groups for NAP, or can someone offer some insight as to how ADRs handle NAP? Thanks.

After several days with the aid of a MS ticket it has been resolved and working well. Too many changes to list here for others unfortunately.

Asking here before raising an MS ticket, but has anyone published Exchange 2013 through Forefront UAG 2010 SP3 (with Rollup 1) and limited it to NTLM authentication? For me, it works for everything except passing RPC through UAG which breaks OA. I followed this guide without issue: Download Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAG from Official Microsoft Download Center The Remote Connectivity Analyser throws an error at: Attempting to ping RPC endpoint 6001 (Exchange Information Store); The RPC_S_SERVER_UNAVAILABLE error (0x6ba) was thrown by the RPC Runtime process. Telnet to the 6001 port internally works fine. I am hopeful someone is running a similar config and I can compare key components.

Although I agree with the comments of the ease and quickness of applying applications in a task sequence, I do believe with a slight change of your thinking user/device affinity would give a similar result. The only other option I can think of is if the applications are advertised (sorry deployed ) to collections for automatic silent installs, run a script that at the end of your task sequence it auto logs on and sits there for a predetermined amount of time. The SCCM client would then carry out the installs (you can even trigger this event). After the set time expires a second script can clean up the auto logon settings and reboot.

Your explanation of the setup is full of inconsistencies, however based on your post #7 I would either suggest using another patch lead or set the interfaces back to auto as a test and see what they negotiate themselves to, which could show an issue if it's not 1000/full. Although your config could be better (not your fault as you say) nothing in it should cause the drops.

A witness or quorum is only needed if there are an even number of hosts. Although I run 4 x 10Gb fully redundant in our environment, the principles are the same, so going back to the OP setup it looks good for your environment. Clustering is only really used if direct access to your storage is not available from a host (traffic is redirected over the network). This should rarely happen so it is safe to pair it with live migration, but if it does occur and you migrate a server you will see a big slow down. You can create separate networks for clustering and live migration or use the same, with management as the secondary in both cases. Both are in different areas of Hyper-V with tick boxes for selecting the networks to use and then ordering the priority. In 2012 you no longer need to set the metric (well I have not, always seems to be correct when I check). I would probably take the spare NIC and add it to the cluster/live migration team.

There are many examples available both from HP and general searching. A good example is from this very forum - http://www.edugeek.net/forums/wireless-networks/69614-vlan-config-procurve.html As gshaw states, it is understanding what is "in" is the greatest hurdle to understanding ACLs. Have a go and if you get stuck post the config.

By giving vlan50 an IP address you're adding it to the route table which is why guests can access everything. You have the right idea, keep the guest network 100% isolated from your inside network and I would usually achieve this by using a dedicated port on your firewall device and let that be the DHCP server. However if you're stuck on using the switch, you may have to throw in an ip-helper and tight ACLs to achieve a similar result. Use your ISPs DNS servers, ip-helper for DHCP, and lock down access to your other subnets with ACLs as well as traffic outside down to 80, 443 and other required ports (such as DNS). Can the Cisco router take on this role?

I do not have Toshiba experience but both HP/Lenovo notebooks are a system board swap for forgotten passwords (as told by their support teams). If it was not the power on password you would have a better chance.

Big picture only - VLAN 1 - untagged - 1, 3, 5, ... , 23 VLAN 2 - untagged - 2, 4, 6, ... , 22 VLAN 3 - untagged - 24 (not sure where you got port 26 on a 24 port switch, but have not looked up this particular model) - for the server VLAN 1 - create a deny ACL to VLAN 2 range VLAN 2 - create a deny ACL to VLAN 1 range Enable IP routing, make sure VLAN 1,2 have ip helper set up for DHCP server. Get this working before you worry about tagging ports which overcomplicates things.

There is a bit it could be, but just basing it on what you wrote have you updated your subnets under AD Sites and Services to include the new VLAN subnets?