djslack

I have had clients who have put their Geovision systems in a domain to the detriment of the system. I don't think this has anything to do with actually being in a domain but some of the group policy settings they were using to lock down the machines prevented the GV system from functioning properly. We had this at one branch of a hospital system; at all other locations everything was fine (machines not put in domain) but at this location someone on IT staff had it in their mind the DVR *had* to be on the domain and they kept breaking network functionality. As kao said I try to convince them not to put the system in a domain... think of a geovision system as an appliance instead of as a PC, and use physical security and/or lock down the system using the geovision keylock or other methods to prevent people from using the system for other than DVR use. If they were using a standalone DVR it could not be on the domain. That said if it "must" be part of a domain and they are using group policy to lock down their stations and the DVR doesn't function properly in the domain, the solution is that their network admins should create a policy for the dvr machine(s) that does not break the DVR... or take the machine out of the domain. Starting Geovision as a service is an interesting idea for machines that are accessed over the network only, it should work well.

Hello all, I do some PC tech work for a company that provides Geovision PC based DVRs. I've been doing it for a couple of months. Some of our clients have multiple DVRs in a single location. Previously these machines have just had separate ports forwarded (i.e. 4550/4551, 5550/5551) although this adds confusion to clients when they go to remote view, unless we go and configure the multiview client at every pc they want to view their DVRs from. I've just been hit with several of these in a row, and there's got to be a better way. I am fairly competent at networking but far from an expert with Geovision. Is there a better way to do this? One-to-one NAT would be great but this isn't widely available in routers and I try not to get too involved with the client's networks, plus it requires they have multiple public IPs. I have seen some of the things on this board where the ActiveX controls are accessed directly instead of using the Multiview client, but assuming the client will use the built-in options (web interface, Multiview, Remote Viewlog) what is the best way to handle accessing multiple DVRs in a single network over the Internet with an eye towards ease of use for the end user?

A router only allows multiple computers to share a single network connection (modem), so you don't need it here. Your modem appears to be handing out addresses via DHCP if you plugged in your laptop and it worked. You should be able to set your DVR to DHCP (otherwise known as "Automatically assign a network address") and it will be online. As others have mentioned, though, unless you specifically have a static IP address provided by your cable/DSL provider, your IP address will change. This is where the dynamic DNS services come in. Alternately you can call your ISP and tell them you need a Static IP address... if they don't charge too much for it this is the easiest way. They will then give you all the IP address, gateway, subnet information you need to put into your DVR to make it work.

Not familiar with that router but if you are seeing the router's page and not the desired interface then one of two things are happening. The most likely is that your router is not correctly set up to port forward. Portforward dot com may help you with your router. The second, less likely, is that somehow you are putting your router's internal IP into dynamic dns. If you're using dyndns download their free updater program to make keeping your dynamic dns up to date hassle free.

Of course the answer depends on your budget and needs, this is assuming you're talking about a small network and consumer-quality gear you can pick up at a big box store. I was going to mention this, I have had a lot of luck with (and prefer to use) Linksys WRT54Gxx for small networks although my experiences with Netgear have been almost as good. But a lot of the shortcomings of any device like this come from the firmware, and the dd-wrt firmware (as well as some other third party firmware packages) is a way to take a $50 linksys (or buffalo, d-link, or many other brands) box and give it capabilities of hardware that costs much more. for advanced networking needs or just better stability it is a great piece of free software. Speaking of great free software in this department, with a spare 486 class or better PC and two NICs you can run m0n0wall and have a bulletproof router that will run circles around anything you can buy for a couple hundred bucks at a big box store as well. It's the best thing you can do with old hardware since doorstops. Both those packages are well worth your time if you like to play with any kind of networking stuff -- though I well understand in our world most times you just want to be able to buy something, turn it on, and let it do its job so you can do yours. If that's the kind of solution you need then you're looking for out of the box stuff - and if you've ruled out the biggest two options you're probably best off to try a belkin or buffalo (though buffalo is apparently experiencing some licensing issues in the US right now) unit, they are about the best respected of the other names out there but I don't know that either one stands out above the rest. I think with consumer level stuff it's equal parts design quality and luck. P.S. I just read your old thread on self-ping problem and rather than resurrect it I figured I'd tack on here. Ping doesn't have a lot to do with it - ping is only a response on one port (the ping service) which a lot of routers disable by default, even if you disable all security. I think Linksys has a specific checkbox in the advanced section to respond to pings on the WAN interface. Many consumer level routers also don't handle the concept of accessing outside ports from inside the local network and sometimes freak out about that - when testing remote web access I always use something like the *hide network (a free web proxy) to come back and hit it from the outside, and use shieldsup from Steve Gibson at GRC's website to test whether specific ports are open. These tips may be handy for you whichever router you choose to go with.