Destinova

Many printer models use a multicast to find other printers on the network, very similar to Bonjour or UPnP. That being said it would not be using a link-local address.

Ruckus controller interfaces cannot be teamed. This is unfortunate if you are tunelling traffic back to your controllers. There are several reasons to do this, VoWLAN is one, traffic shaping and QoS is another. It's one of the principal arguments against using a controller-based solution as your controller becomes a bottleneck for your traffic.

1) Do you currently have BYOD? Yes for both staff and students. 3) If you have it, do you limit access to authenticated Internet only? Segregated captive portal wireless access. AD credentials (802.1x using Cisco Secure ACS) to authenticate, grants access to content filtered internet only. 4) If you have it, what's been the impact on your Broadband? No worse than before, except when Apple releases an iOS update and every fruitpad/fruitphone in the division updates over the air, at the same time. Also, Bonjour is a particularly nasty protocol, block it if you can unless you have all of your multicast locked down neatly. 5) If you have it, is it regarded as a successful facility? Yes and no. Our wireless access was never planned for high-density, so where there are large numbers of devices in a small area, performance suffers. Administration too cheap to deploy proper wireless. We would prefer to move towards an RDI solution, but once again costs for the infrastructure to support that are high, although this is the final goal. 7) If you DO have it, what have been your major pros and cons? If it's theirs, they tend to take care of it. Not the case with school-provided equipment.

Glad to hear you at least got your sanity saved!

I've had issues with IGMP snooping and multicast. If it isn't configured properly across every switch that multicast traffic is going to pass, you'll run into problems. Spanning tree being what it is, unless your topology includes multiple redundant links, I don't know that is where you'd have an issue although you won't see these ports as blocked per se, unless you are actually looking at their STP state. To test the multicast theory you can disable IGMP snooping on all your switches. This is a temporary test and I do not recommend this as a permanent solution but it may point to whether or not this is a multicast problem. A topology if you are able to provide one to us would also help diagnose what the issue might be. Cheers. Edit: Having just read about turning off the IPTV server I'd point at a multicast routing issue. Try and find out what multicast IP that server is using, there may be a conflict with another multicast service.

I'd also suspect STP but noticing you have some iSCSI traffic on there as well I'd check for multicast issues.

From the release notes for v9.4: I know most of us are stubborn male types who won't ask for directions or read the manual, but sometimes it helps.

Yes, that's correct. I was under the (incorrect) impression that's what he was looking for. With the diagram I realize there's an actual second physical router, which tosses things back to PBR.

So which interface(s) have the IP address for 192.168.52.1 and 192.168.53.1 ? I'm a bit confused here maybe a network diagram would help if you have one.

Do you have layer 3 interfaces for those addresses?

Where do you want the traffic to go, rather than 192.168.60.1 ?

A vlan is just a subnet - if you want static routing just specify a route for the subnet of the vlan you want to change: ip route 192.168.52.0 255.255.255.0

Sure - with the caveat that this is Cisco syntax - I've not done much work with HP gear at layer 3. The "old way" or router on a stick using subinterfaces on your router for each vlan: interface GigabitEthernet0/0 description Inside1 no ip address duplex full speed 1000 media-type rj45 interface GigabitEthernet0/0.1 encapsulation dot1q 1 native ip address 192.168.60.2 255.255.255.0 (not sure of what mask you wanted here...) interface Gigabitethernet0/0.52 encapsulation dot1q 52 ip address 192.168.52.2 255.255.255.0 interface GigabitEthernet0/0.52 encapsulation dot1q 53 ip address 192.168.53.2 255.255.255.0 etc. Each vlan uses these addresses as it's default gateway. Alternatively, and the current recommended way - at least in the Cisco world - is to have a layer 3 switch as your gateway - this way inter-vlan routing is not hairpinning on the router. This just uses layer 3 vlan interfaces rather than subinterfaces: interface vlan 1 ip address 192.168.60.2 255.255.255.0 no shut interface vlan 52 ip address 192.168.52.2 255.255.255.0 no shut interface vlan 53 ip address 192.168.53.2 255.255.255.0 no shut Then whatever routing protocol you want and advertise those routes to your router (of course you need to run the same protocol on the router to advertise your WAN links) router ospf 1 network 192.168.60.0 0.0.0.255 area 0 network 192.168.52.0 0.0.0.255 area 0 network 192.168.53.0 0.0.0.255 area 0 Static routes can also be used if you want to specify a different path for specific traffic.

It doesn't need to get as complicated as PBR - you simply need layer 3 addressing for each subnet and then route based on that. Your layer 3 switch can be used or you can have subinterfaces on the router for each vlan. Then either using static routes to point each vlan at it's next hop, or a dynamic routing protocol like OSPF or EIGRP to dynamically propagate the routes you want.

Yes you can have separate routing for each vlan on a layer 3 switch.

I used to run with DHCP on the AP's but had an issue that's made me move them to static. I have several rural schools that have flaky power. In the event of a power outage that outlasts our UPS, once power is restored the local domain controller takes longer to boot than the AP's do so they aren't able to get a lease right away. Setting them to static they are up and running much faster after power comes back up.

Cisco's SRND docs for Unified Communications can be found here: Cisco Unified Communications System The principles here apply to any voice design:

Excellent. I'll be attending our local Apple Learning Tour tomorrow morning and hope to elicit the same from them. Really, until they make the VPP available, what else are we to do?

This isn't a regional restriction. Several other UK based techs have pointed this out in some of the other iPad discussions here. The limitations are as follows: 5 computers authorized for iTunes content 10 devices sync'd to a single iCloud account Unlimited iOS devices sync'd to a single iTunes account - this includes iPhones, iPods, iPads, and Apple TV's Using a single master account you can synch all of your devices and apps. Yes it's a clear licensing violation, but until the VPP is available in your area, it's the simplest workaround.

The 10 device limit applies to iCloud services. You can sync an unlimited number of iOS devices to a single iTunes account.

No, this does not happen after a restart. We are using Deep Freeze so a restart returns the PC to it's original state and that profile no longer exists locally. Yes, Windows is definitely hanging onto that file for some reason.

Administrators (\Administrators) Verified at another site that does not have this issue, the same group has ownership.

You asked if I applied "correct security to the registry hive", yes.

Security is good. These profiles have been in place for about 5 years, no changes other than we migrated the servers from 2003 to 2008R2.

I'm at the point of offering a bounty for a solution to this... We have students set up using a single shared mandatory profile, and all lab computers use Deep Freeze. We have recently had one school that has been experiencing students getting the default profile rather than the student profile. In testing we've found the initial login on a clean recently rebooted PC (XP SP3) works fine. Then if we log out and log back in right away we get the following error: Windows cannot copy file \\\studentprofile\Cookies\index.dat to location C:\Documents and Settings\\Cookies\index.dat. Possible causes of this error include network problems or insufficient security rights. If this problem persists, contact your network administrator. DETAIL - The process cannot access the file because it is being used by another process. Logged as Event ID: 1509 They are then logged in with the default system profile which means no GPO, etc. so they have access to command prompt, control panel items, etc. essentially a local admin account. The student profile has not been changed in any way, nobody has any write permissions to it - strictly read only. All date stamps on the profile objects are evidence. Permissions are fine - as again indicated when the initial login works without issue. Something somewhere is hanging onto that .dat file and we can't figure out how to resolve it. If anyone has seen this before and has any idea of what might be causing it, please let me know. Cheers, Rob