Saturday, August 28, 2010, 08:32 AM
Verdict: Not to use.
The reasons:
- Network Maintenance time/work is still required anyway.
- Deep Freeze is not a replacement for antivirus or patching systems. In fact,
- Faronics (who makes Deep Freeze) sells their own antivirus product to integrate with Deep Freeze.
- And Deep Freeze provides a means to have a scheduled maintenance window to "thaw" (unfreeze) computers, so that network administrators can install patches and apply updated antivirus signatures.
- Deep Freeze is not a replacement for antivirus or patching systems. In fact,
I have been aware of Deep Freeze for at least 4 years. It is an interesting concept, but something that I have not ever decided to look into using.... until now. My company recently started doing work for a new client whose network is setup to use Deep Freeze. As we essentially were given the opportunity to become their primary I.T. provider, we decided that we really needed to take a thorough look at Deep Freeze so that we could appropriately advise them on the long-term route to take in managing their network. I may add that this is a small medical office with 1 server + 10 PCs.
It is also important to mention that this particular client also had Deep Freeze installed on their server, and have operated for 3+ years with the server generally in a "Frozen" state. This is significant, as the server is a domain controller which implies also a DNS server. It is a Microsoft SQL 2005 server, and serves various data files which the client PCs access via UNC paths.
I was familiar with the concept of Deep Freeze, but was left with a lot of questions regarding its actual implementation and the effects/implications it may have on data/databases & overall functionality on specific systems/components such as:
Active Directory
DHCP
DNS
Windows Event Logs
IIS Logs
Other Logs
SQL Databases
Other Application Databases/Data
Software & Operating System Patches
Antivirus
I first spoke with the I.T. person who previously managed their network. He did not have enough good things to say about Deep Freeze, and strongly recommended that I use it with all of my customers. The specific answers he gave to my questions were:
- Deep Freeze is not a replacement for antivirus software, and that you should still have antivirus.
- Deep Freeze has the ability to schedule maintenance windows for patch installation on clients (schedule clients to reboot thawed out at 10pm, have patches & A/V updates applied, then reboot frozen again at 4am)
- He thinks that Deep Freeze makes some kind of exception for Active Directory, so that a domain controller can be "frozen" without the Active Directory database being affected
Next I spoke with my cousin Todd, who used to work in a school district I.T. department that discontinued using Deep Freeze while he was working there.
Next we checked with the Faronics website
Next we spoke with Faronics Tech Support
Lastly I did more research online.
[ add comment ] | permalink |
( 2.9 / 31 )Wednesday, March 31, 2010, 09:32 AM
I have a TrixBox CE 2.6.1 system, which is updated to FreePBX 2.5
I think since we ever deployed this box, we have been having issues with calls that somehow get stuck in a state that they are never hung up. The result is that one of my channels gets tied up forever until I manually go in and kill the call.
See image:
The above hung call shows a duration of 1340:40:52 (which is 1,340 hours, 40 minutes and 52 seconds, A.K.A. 55 days, 20 hours, 40 minutes and 52 seconds), and is still counting up. Could that be right?
I'm not sure how to find more info about the currently hung call, but I need to figure out what is causing this and how to prevent this. As my customer only have a few channels, giving one up for a few days until someone notices that it is not available to the system doesn't work for these guys.
In this example the hung call is on a SIP station that is not currently registered. Don't ask me how a call can be active with an extension that is not even online. I'm pretty sure that other times that this happens, it has been with extensions that are online/registered. So I think that the fact that this extension (703) is not currently registered is irrelevant to the problem.
Also, just a rundown of our channels. Zap channels 1-4 are a PRI, and 25-26 are standard POTS lines. Outbound calls first use the POTS lines, then switch over to the PRI when the POTS are already in use.
One thing I haven't paid attention to is whether this only happens with the POTS lines (channels 25-26), or the PRI channels too.
I appreciate any input.
[ add comment ] | permalink |
( 2.9 / 404 )Tuesday, January 26, 2010, 05:12 PM
This is just something that I feel the need to vent about. It works great with SBS 2003 (generally takes us 3 hours to get the first BlackBerry syncing with the BPS server). But with SBS 2008, the only way to do it is to have a 32-bit Server 2003 member server that takes care of the BPS needs. And this can be expensive. This has been an issue for over an year, and I think it is all the more reason not to use BlackBerries if you work in a Small Business environment. Exchange Activesync is pretty much a standard these days (for a licensing fee from M$). And there are plenty of phones out there that will talk directly to the Exchange 2007 (or 2003) server and sync up email, calendar, contacts, notes, tasks, etc OTA no problem, while keeping the advanced security requirements.
Other phones that do this well are:
Windows Mobile phones
- iPhone
- Palm Palm OS
- Palm WebOS
- Android
- Any phone compatible with RoadSync (made by DataViz)
and the list goes on...
Except for RIM's BlackBerry phones.
RIM drives me crazy that they are unwilling to let their phones talk directly to the Exchange server. They just don't want to give up the revenue they get out of the BIS service and BES and BPS licenses....
Aargh!! :-)
[ add comment ] | permalink |
( 3 / 433 )Sunday, September 20, 2009, 11:01 PM
They have since been bought out by Citrix, but I still really like their virtualization platform. I use it & rely on it every day for my business. I currently have 5 virtual servers running on one Dell PowerEdge 1950 w/ quad-core Xeon 1.6Ghz CPU, running Citrix Xen Server 5.0. I am planning on upgrading to 5.5 soon so that I can use Debian Lenny as a guest VM OS. But first I want to get my NAS up via iSCSI, and a 2nd Xen Server physical host. This way I can move running VMs from one server to the other without incurring any downtime. This will allow maintenance during business hours, etc without any customer service disruption.
This stuff is pretty sweet indeed.
[ add comment ] | permalink |
( 3 / 651 )Thursday, July 17, 2008, 03:22 PM
Well, quite some time back I decided to make some adjustments to my Citrix XenServer to allow to have a subinterface (a.k.a. a second IP address) on the internal interface that I use for connecting to and managing it with XenCenter. This was only temporary while I was moving offices. Well after I finally moved the physical server to our new office I did everything that I could think of and find to reverse my initial changes so that everything dealing with the XenCenter management would be back to the defaults setup when XenServer 4.0 was installed. In addition to changing some of the system networking within the CentOS 5 host operating system, I also had to change some files that were specific to the XenServer and its admin connectivity. It took me forever to finally get it all back to normal. It wasn't too bad getting connectivity from XenCenter again, but after that I could never seem to get the console tab to actually show the console from any of the child servers, or the XenServer itself. I couldn't find anything on it on the internet. This kind of leads me to believe that most other admins have either been smart enough to not mess with some of the intracacies of the XenServer settings, or they were smart enough to note what they were so that they could reverse them, or they weren't smart enough to change them in the first place :-)
In any case, the file /etc/issue needs to contain the IP address that the XenServer will be managed from using XenCenter. If not, the console functions in XenCenter don't work.
At the same time that I modified the above file to reverse my original changes, I also removed the subinterface. So I'm not positive which change fixed it. But the IP address listed in /etc/issue was the one that I had used temporarily on the subinterface, and I'm pretty sure that I had modified that file, as it turned up in my list as one of the files that had been modified on the system since 1/1/08.
So for any other XenServer sysadmins who may have fouled up access to the console function in XenCenter, I hope this helps you!
Oh yeah. One more thing. After changing those settings, things didn't start working again until I restarted /etc/init.d/xenapi and /etc/init.d/xenapissl
[ 1 comment ] ( 12 views ) | permalink |
( 3 / 1084 )Next
