AdonMalik

I haven't seen that particular issue before with sysprep but your description of the steps you took prior to capturing the image seems correct. Typically I throw sysprep the direct path to the unattend file and the shutdown switch as well but that shouldn't be the cause of this problem. Make sure that you're throwing sysprep /OOBE though instead of /OOB; if not that's probably the issue right there. If that's not it then you might try deploying the image to a virtual machine to see if you can reproduce the issue there as well. While it won't rule out hardware if it still fails it will at least give you a bit more info if it ends up succeeding.

I can't find any info on compatibility with either of those two systems but you might consider looking into Koha (Official Website of Koha Library Software) or Evergreen (Evergreen ILS | Evergreen – Open Source Library Software). Both are very good open source ILS and you could likely contract with a programmer to build in support for those two systems if it isn't already present. For Koha a good place to start would be ByWater Solutions (Koha Open Source ILS Support from ByWater Solutions) as they are one of the largest suppliers of commercial support and hosting for it. I'm not as familiar with the support ecosystem for Evergreen though so I can't point you in a good direction there but I'm sure their website or forums would be able to give you some ideas. Hope that's of some help at least.

Does anyone have any real world experience with either the EMC VNXe 3200 or the Dell Compellent DC4020 that can give me an idea of how they compare to one another? I'm looking to replace an aging all in one server system and am by no means a storage engineer so I'm attempting to make as educated of a decision as possible. Any pros, cons, pitfalls, etc that people could share with me about these products would be appreciated. Also it's very possible I'm missing a giant elephant in the room even attempting to compare these two solutions so if I am please speak up .

While I haven't tried this on a Pi yet what I'm planning to do for our permanent units (the ones that will be imaged and controlled by IT, not the ones we're going to teach OS installs on in other words) is install SAMBA and do a domain bind so that users will be able to use their network credentials to log in to the Pi. From there I'd just have the system mount their home drive since they're already domain authenticated it should work without an issue. It's been a while since I did the modifications to a stock Linux install but it shouldn't be terribly difficult on most modern distros. Edit: It's a bit old but all the steps should be roughly the same: http://technet.microsoft.com/en-us/magazine/2008.12.linux.aspx?pr=blog.

We've had success with an open source system called GLPI (GLPI - Gestionnaire libre de parc informatique). While it doesn't have a specific mobile app it can be pulled up on a mobile device with full functionality. If you pair this with OCS Inventory NG (OCS Inventory NG | Home) you can actually automate your inventory process by using the device client to check in automatically with the inventory system. Let me know if you have any questions about either of them and I can probably field most of them to save you a bit of time digging through the wikis.

The short answer is that to do this you'll need to install the intermediate CA or root CA public cert into the trusted certificate store of every device that connects to HTTPS sites through it. The reason for this is that the client is actually only making a SSL connection to your Squid box, not the site they think they're going to. As a result Squid can only give them the certificate it has for the signing of connections. Since the Squid box is essentially performing a man-in-the-middle attack on the connection it would need the private key of each site visited in order to resign the connection when it's passed to the internal client. This is actually a security mechanic of SSL so it's not something you can really bypass. You could push the intermediate CA cert through a GPO pretty easily though; if you want details let me know and I'll pull them from out GPO that does that very thing. The other part to consider in all of this is that SSL interception is likely required to be disclosed to the end user under UK laws (it is in most countries) but IANAL or based in the UK so I'm not able to say for certain. Even if it's not disclosed anyone inspecting the certificate that is encrypting their connection can figure it out due to what you have to do in order to squelch the browser warnings when implementing this. Hope that helps .

We've used ClearOS for years with decent success. It's not perfect but it's certainly better than manually configuring Squid, DansGuardian, and IPTables by hand. It can take a bit of tinkering to get everything to work exactly how you want sometimes but overall it's pretty easy to install and configure. You can purchase support as well so if that's in your budget it's always an option as well.

I don't have experience with that particular product (or Meraki's Firewall line in general) but the issue you're describing sounds like HTTPS inspection/interception isn't turned on. In my experience most firewalls/proxies don't handle this well in transparent mode so you may need to check the proxy settings that are being used on the devices to ensure they're actually configured to force proxying of connections. Two things to keep in mind if you're doing HTTPS interception: 1) You will need a valid cert installed on the proxy/firewall that is signed by a Certificate Authority that all of your devices are configured to trust (so an internal CA that's pushed to the trust store or an external CA like Versign) 2) Depending on the laws in the UK you are likely required to clearly notify users that their HTTPS connections are being intercepted and to exclude bank and health care sites from inspection. IANAL (or in the UK) so this is merely what I have been told in the past in regards to UK law.

Ok I think I'm grasping your layout now so here are my thoughts currently: 1. My understanding is that the WatchGuard XTM505 is a UTM/NGF device. Now I'm not very familiar with the WatchGuard product line and feature set so it may not have this capability but I'll give it here as an option just in case. On some UTM devices you can segregate ports into essentially discrete virtual appliances (it's called VDOMs on FortiGate products). If your WatchGuard has a similar capability you wouldn't necessarily need to remove routing from taking place on that device and would potentially be able to have more fine grained control of traffic between subnets if you enabled VDOMs. Now this is a lot of extra configuration and would put additional load on the WatchGuard so before attempting to do that I'd advise you thoroughly go through the documentation for your WatchGuard to make sure everything will work how intended and be within your device's capability to handle the extra load. I can help you rough out at least a framework of how this would work if that's the route you want to pursue. 2. Now in the scenario of having the 3500 as your router you only need IP Routing enabled on the 3500; it should be disabled on the 2910's with the 'no ip routing' command so that it doesn't get in the way of what you're trying to do. The ip routing directive turns each switch it's enabled on into a router so it gets in the way here since you only want the 3500 to be acting as a router. As I recall trunking is not required for this config to work but I have it enabled for the sake of making future expansion of our network easier to accomplish; it wouldn't hurt to enable it for each link however. Additionally you'll notice in the config files that follow that I have all of our VLANs configured on both switches even if only the Trunk is a member; again this was done for ease of future expansion and shouldn't be required. However it is critical to make sure that all of your VLAN numbers match between switches. It appears you've already done this but just keep in mind if the VLAN numbers don't match then this won't work correctly as the switches will get confused. Also you shouldn't need the IP Default Gateway configured either since you have a static route that does the same thing. You will need a static route on the WatchGuard for the subnet on the 3500 as we talked about previously. The only two static routes you should need in this config are: a) a static route on the WatchGuard telling it to sent all traffic for 10.20.28.0/22 to the 3500 IP that's on the same subnet as the WatchGuard (ie ip route 10.20.28.0 255.255.252.0 <3500 IP>) b) a static route on the 3500 telling all traffic destined to any place that is not directly connected to the 3500 to be sent to the WatchGuard IP (ie ip route 0.0.0.0 0.0.0.0 ) Here are the pertinent sections of our two 3500 switches for your reference I still have a bit of config cleanup to do so please ignore the parts that are a bit messy : Core Switch (acting as router): trunk 27-30 trk1 trunk trunk 31-34 trk2 trunk trunk 48 trk3 lacp no telnet-server ip route 0.0.0.0 0.0.0.0 172.16.10.3 ip routing router rip redistribute connected enable exit vlan 1 name "DEFAULT_VLAN" no untagged 1-26,35-47,Trk1-Trk3 no ip address forbid 1-25,35-39,41-47 exit vlan 2 name "Data" untagged 18,25,37,42-45,47 tagged 46,Trk1-Trk3 ip address 192.168.100.10 255.255.255.0 ip igmp exit vlan 3 name "External" untagged 26 tagged Trk1-Trk2 no ip address exit vlan 10 name "Voice" tagged 1-17,36,39,41,46,Trk3 no ip address exit vlan 20 name "Servers" untagged 20 tagged Trk1-Trk3 ip address 172.16.10.1 255.255.255.224 exit vlan 21 name "Management" tagged Trk1-Trk3 ip address 172.16.10.33 255.255.255.240 exit vlan 22 name "Printers" untagged 3,39 tagged Trk3 ip address 172.16.10.49 255.255.255.240 exit vlan 23 name "RJ45_Ports" untagged 1-2,4-17,36,40-41 tagged Trk3 ip address 172.16.12.1 255.255.254.0 ip helper-address 172.16.10.6 exit vlan 24 name "Wireless" untagged 19,21-24,35,38 tagged Trk3 ip address 172.16.14.1 255.255.254.0 ip helper-address 172.16.10.6 ip rip 172.16.14.1 exit spanning-tree Trk1 priority 4 spanning-tree Trk2 priority 4 spanning-tree Trk3 priority 4 Slave Switch (extending subnets to more ports): trunk 48 trk3 lacp no telnet-server vlan 1 name "DEFAULT_VLAN" no untagged 1-47,Trk3 no ip address exit vlan 2 name "DATA" untagged 1,4,6-14,19,23,25-26,30-35,39-40,43-45,47 tagged Trk3 ip address 192.168.100.20 255.255.255.0 exit vlan 10 name "VOICE" tagged 1-17,19,22-23,25-47,Trk3 no ip address exit vlan 20 name "Servers" tagged Trk3 ip address 172.16.10.2 255.255.255.224 exit vlan 21 name "Management" tagged Trk3 ip address 172.16.10.34 255.255.255.240 exit vlan 22 name "Printers" tagged Trk3 ip address 172.16.10.50 255.255.255.240 exit vlan 23 name "RJ45_Ports" untagged 2-3,15-17,22,27-28,36-38,41-42,46 tagged Trk3 ip address 172.16.12.2 255.255.254.0 exit vlan 24 name "Wireless" untagged 5,18,20-21,24,29 tagged Trk3 ip address 172.16.14.2 255.255.254.0 exit spanning-tree Trk3 priority 4 Hope that helps you get this working.

FYI on the 3500 you need to use the command 'show ip route' in order to see the routing table; 'show route' and 'show route-map' will not show you the info you need.

Not sure if you're still having this issue or not but I should be able to help if you still are as we're successfully doing essentially what you're attempting to do using two HP Procurve 3500yl. I see a couple of things that may be causing this not to work properly. 1) You do not need static routes when the 'ip routing' directive is turned on as that directive enables dynamic routing. This means that the switch is building the route table based on any routing protocols you have turned on and based on networks it is directly connected to. Based on your description my guess is that you don't have any devices broadcasting route updates but I may be incorrect. If you DO have another device broadcasting route updates and both it and the 3500 think they are the router for the same network that is likely where your conflict is as the 3500 is currently configured to listen for RIP updates. 2) If you want DHCP to work between subnets and VLANs you must add 'ip helper-address ' to each VLAN that the DHCP server does not reside on. You will need to configure a scope for each subnet you'd like your DHCP server to hand out addresses for. Please note that the scope must match the address range used for the switch's IP address that the DHCP request entered the switch on (ie you must have a scope for 192.168.1.0/24 if the switch IP that the request originated on is 192.168.1.1/24). For this to work all clients and servers must be using the switch's IP address for their VLAN as their gateway; the default route on the switch will handle routing traffic to your edge device. 3) As long as the 2910 switches serve no other VLANs besides the one assigned to the 192.168.1.0/24 network on the 3500 you should not need trunking or tagging enabled on those ports. In that configuration the 2910 switches would actually need no VLANs configured even. If you do have VLANs enabled on the 2910s however then you should enable trunking on any switch interlinks. This would need to be configured on both ends and VLAN numbers would have to match on all switches. You would then want the trunks tagged on all switches. 4) You need a static route on 192.168.1.1 for the 10.20.28.0/24 network pointing to 192.168.1.250. Depending on what brand the 192.168.1.1 device is the command for this will be different but it should look something like 'ip route 10.20.28.0/24 gw 192.168.1.250'. If you make those changes everything SHOULD work. If not please post the configs of the 2910 switches as well so we can go through things in more detail .