Wish I had something totally enlightening to share. I've got so many implementation projects, though, that I'm basically just running around trying to get all of them done.
I am beginning to plan out budgets for 2009; with the construction industry being as down as it is, there's no way I'm spending much money next year. But in 2009 we're going to need some server upgrades, and we're also predicting that the industry will be doing better. So I'm thinking disk space.
I looked at a SAN back in 2005 when we originally purchased most of our servers. It was prohibitively expensive. I've heard that they're cheaper now. But just as important as price is storage space--I've got things demanding 300-500GB of space now. I just can't keep up, especially when trying to deal with internal storage. Some kind of SAN seems like the only sane option.
Friday, August 31, 2007
Wednesday, September 01, 2004
Wow, it's been 6 months. I'm getting really bad at this. Well, I'm going to try to fix that, because I've done a TON in the past 6 months. I want to mention one thing today, but here's a list of stuff I'll try to crank out in the next few days:
Windows Print Queueing from Unix (allowing for true FIFO and archiving)
What ever happened with our phone system?
DID Based faxing
Active Directory and Group Policy actually do rock
How to make WAN printers work over dialup
I'm sure there' s more. But today it's just a plug for an app I've used for the past year, and love it more and more every day. It's called Servers Alive, from Woodstone Consulting (www.woodstone.nu/salive). At it's simplest level, it's an alerting program. If something goes down, it alerts you. But it's so much more.
For starters, it's either cheap or free, depending on how you're using it. If you only have up to 10 devices or services to check, it's free (of course, they'd like you to register, and I'm sure the support is better once you do). For up to 100 services or devices, it's $100--well worth it for us.
Servers Alive isn't just a basic Ping utility. While it can ping a device (and that's primarily how I use it), it can also check any number of services or other protocols. It can check IPX connectivity, it can see if your web server is running, etc. And even the Ping check is fully featured--it doesn't just tell you if the device is gone; you can configure it to tell you if it's running slow as well.
You configure each check that you want to do. Then, you configure alerts. What's great is that it doesn't just offer the option to tell you when it's down. Most of my servers I have set to alert me after two down "cycles" (more on that in a sec), and then again once it's back up. That way if there's a brief "hiccup" on a WAN line, I'm not getting paged about it. I also get "reminder" pages at certain intervals.
As for the cycles, you can configure that as well. By default, it has "day" and "night" settings for weekdays, Saturdays, and Sundays. Since we are a 6-6 operation on weekdays, and closed on weekends, I've set "day" to be 6am-6pm. On week "days", it checks every two minutes (so, if something goes down, I get paged no more than 4 minutes later). On nights and weekends, it checks every 15 minutes (and I might bump that out even further).
Back to alerts for a second. It supports SMTP email, dialing via a modem to a pager or cell phone, and a whole slew of other functions. All I use right now is SMTP email, but once I start talking about our WAN redundancy solution, I'll be using more features of it. But if I told you now I'd have to kill you... :)
Windows Print Queueing from Unix (allowing for true FIFO and archiving)
What ever happened with our phone system?
DID Based faxing
Active Directory and Group Policy actually do rock
How to make WAN printers work over dialup
I'm sure there' s more. But today it's just a plug for an app I've used for the past year, and love it more and more every day. It's called Servers Alive, from Woodstone Consulting (www.woodstone.nu/salive). At it's simplest level, it's an alerting program. If something goes down, it alerts you. But it's so much more.
For starters, it's either cheap or free, depending on how you're using it. If you only have up to 10 devices or services to check, it's free (of course, they'd like you to register, and I'm sure the support is better once you do). For up to 100 services or devices, it's $100--well worth it for us.
Servers Alive isn't just a basic Ping utility. While it can ping a device (and that's primarily how I use it), it can also check any number of services or other protocols. It can check IPX connectivity, it can see if your web server is running, etc. And even the Ping check is fully featured--it doesn't just tell you if the device is gone; you can configure it to tell you if it's running slow as well.
You configure each check that you want to do. Then, you configure alerts. What's great is that it doesn't just offer the option to tell you when it's down. Most of my servers I have set to alert me after two down "cycles" (more on that in a sec), and then again once it's back up. That way if there's a brief "hiccup" on a WAN line, I'm not getting paged about it. I also get "reminder" pages at certain intervals.
As for the cycles, you can configure that as well. By default, it has "day" and "night" settings for weekdays, Saturdays, and Sundays. Since we are a 6-6 operation on weekdays, and closed on weekends, I've set "day" to be 6am-6pm. On week "days", it checks every two minutes (so, if something goes down, I get paged no more than 4 minutes later). On nights and weekends, it checks every 15 minutes (and I might bump that out even further).
Back to alerts for a second. It supports SMTP email, dialing via a modem to a pager or cell phone, and a whole slew of other functions. All I use right now is SMTP email, but once I start talking about our WAN redundancy solution, I'll be using more features of it. But if I told you now I'd have to kill you... :)
Saturday, February 14, 2004
Now an aside. Our new phone system is in. PRI should be installed Monday. SBC has moved the date out a number of times, but the guy that's assisting in the phone system installation, who also works for the SBC reseller that ordered our PRI for us, says he's coming out to test it on Monday, and I'm confident in his confidence.
We've purchased a 3Com NBX system. Specifically the Superstack 3, with redundant hard drives and power supplies and 250+ hours of voicemail recording. I add the "+" because I've been told that the 250 hours was the figure with the original Superstack 3 with a 10GB hard drive. They put in whatever hard drive is most cost efficient--rumor is it's a 40GB now. And we get to use all of it. Of course, we've got 3 hours of voicemail on our old system, so having 1000 hours now isn't gonna matter that much. :)
The NBX can technically be called a Voice over IP (VoIP) system, but that's more of an added ability that it has. At it's core it's an ethernet based system. All of the phones are ethernet based. By default they work at layer 2, so they never even touch IP. But they definately can.
I fell in love with the NBX a few years ago when I saw it on an episode of Hometime. Of course, they had the money to install a (installed, at the time) $2000 phone system in a house. My wife doesn't quite understand why I would want one at my house. To me, the idea of making everything in a home or business ethernet based makes perfect sense. Make every jack an active ethernet jack. No more wondering "What is this one" or "How do I move this extension". Even a lot of VoIP systems are simply VoIP at their core, and still use "traditional" PBX style phones. I did some serious looking at phone systems (I wasn't going to make a $30,000 purchase for my company based just on an episode of Hometime), and found that my original feelings were accurate--I like the idea of a networked phone.
One thing that the 3com system differs from it's competitors in is in the idea of one large system as compared to multiple connected systems. Most VoIP systems are strongly centralized. You've got one massive server that runs most everything. Some systems, like the Shoreline, add some redundancy by separating out call management to seperate devices that can be spread throughout the network, while still being managed as one system. For most companies, this is probably ideal. For us it isn't. We don't have the resources to spend on the redundant high speed WAN connections that a traditional VoIP system would need.
The NBX, on the other hand, operates independently at each site where we install it. The systems can communicate with each other, allowing for simple site to site calls. But if the line goes down, everybody is still up and running happily. No phone calls are lost.
Enough about the system, though--onto why I brought it up. I've got a 3Com phone at home right now. Like I said, they can easily do IP--they just don't by default. I've got the phone running over the XP VPN server that I built. But one of the difficulties that I've faced since I started looking at phone systems is the fact that upper management will probably want a phone at home, but I won't want to maintain some sort of VPN router for their house. Originally I was also concerned about getting them static Internet IPs, but the XP server removes that need. Now if only I could remove the need for the VPN server (without punching holes in the firewall).
Each of them has a Windows XP machine at home already. It finally hit me this week--I don't need a separate router. So, here's the plan:
I'll configure the broadband firewall at each person's house to use a "unique" address range. I'll have to maintain records of this. I can't have them all using 192.168.1.x like they do now. So perhaps Manager 1 will use 10.0.1.x, Manager 2 will use 10.0.2.x, etc.
I then enable IP routing on their XP workstation at home, and give it a static address in that range.
I set up their networked phone with an IP address in that range as well. The phone, though, will use the address of the XP workstation as it's default gateway.
I configure the remote access settings of their user ID to route traffic for their specific 10.x.x.x network through their VPN connection. (I realized this morning that I'll have to do a blog entry on this)
Now, when their VPN connection comes up, the phone connects and is available for use. When they disconnect, the phone goes offline. All they really have to do is plug the phone into the switch on the broadband router, and everything should work.
I'm looking forward to trying this out this coming week. I'll keep everyone posted.
We've purchased a 3Com NBX system. Specifically the Superstack 3, with redundant hard drives and power supplies and 250+ hours of voicemail recording. I add the "+" because I've been told that the 250 hours was the figure with the original Superstack 3 with a 10GB hard drive. They put in whatever hard drive is most cost efficient--rumor is it's a 40GB now. And we get to use all of it. Of course, we've got 3 hours of voicemail on our old system, so having 1000 hours now isn't gonna matter that much. :)
The NBX can technically be called a Voice over IP (VoIP) system, but that's more of an added ability that it has. At it's core it's an ethernet based system. All of the phones are ethernet based. By default they work at layer 2, so they never even touch IP. But they definately can.
I fell in love with the NBX a few years ago when I saw it on an episode of Hometime. Of course, they had the money to install a (installed, at the time) $2000 phone system in a house. My wife doesn't quite understand why I would want one at my house. To me, the idea of making everything in a home or business ethernet based makes perfect sense. Make every jack an active ethernet jack. No more wondering "What is this one" or "How do I move this extension". Even a lot of VoIP systems are simply VoIP at their core, and still use "traditional" PBX style phones. I did some serious looking at phone systems (I wasn't going to make a $30,000 purchase for my company based just on an episode of Hometime), and found that my original feelings were accurate--I like the idea of a networked phone.
One thing that the 3com system differs from it's competitors in is in the idea of one large system as compared to multiple connected systems. Most VoIP systems are strongly centralized. You've got one massive server that runs most everything. Some systems, like the Shoreline, add some redundancy by separating out call management to seperate devices that can be spread throughout the network, while still being managed as one system. For most companies, this is probably ideal. For us it isn't. We don't have the resources to spend on the redundant high speed WAN connections that a traditional VoIP system would need.
The NBX, on the other hand, operates independently at each site where we install it. The systems can communicate with each other, allowing for simple site to site calls. But if the line goes down, everybody is still up and running happily. No phone calls are lost.
Enough about the system, though--onto why I brought it up. I've got a 3Com phone at home right now. Like I said, they can easily do IP--they just don't by default. I've got the phone running over the XP VPN server that I built. But one of the difficulties that I've faced since I started looking at phone systems is the fact that upper management will probably want a phone at home, but I won't want to maintain some sort of VPN router for their house. Originally I was also concerned about getting them static Internet IPs, but the XP server removes that need. Now if only I could remove the need for the VPN server (without punching holes in the firewall).
Each of them has a Windows XP machine at home already. It finally hit me this week--I don't need a separate router. So, here's the plan:
I'll configure the broadband firewall at each person's house to use a "unique" address range. I'll have to maintain records of this. I can't have them all using 192.168.1.x like they do now. So perhaps Manager 1 will use 10.0.1.x, Manager 2 will use 10.0.2.x, etc.
I then enable IP routing on their XP workstation at home, and give it a static address in that range.
I set up their networked phone with an IP address in that range as well. The phone, though, will use the address of the XP workstation as it's default gateway.
I configure the remote access settings of their user ID to route traffic for their specific 10.x.x.x network through their VPN connection. (I realized this morning that I'll have to do a blog entry on this)
Now, when their VPN connection comes up, the phone connects and is available for use. When they disconnect, the phone goes offline. All they really have to do is plug the phone into the switch on the broadband router, and everything should work.
I'm looking forward to trying this out this coming week. I'll keep everyone posted.
Well, it's 5:40am on Saturday. I've discovered that alcohol (in moderation) is the perfect sleep inducer for me--I sleep like a rock for a few hours, and wake up wide awake (which never happens usually). But when you go to bed at 9:30pm (hey, I was tipsy after dinner, and feeling really tired! :) ), that few hours puts you up at 2:30 in the morning.
So, why not blog?
Routing in XP. It's still pretty simple to turn on, although not as easy as it was in NT 4 (check "Enable Routing"). There's a registry update necessary. You can find it pretty much anywhere on the net, including here:
Stupid little note: Changing the registry is dangerous stuff. I've heard of people losing limbs. Sprouting a second head is a very real possibility. You've been warned--anything you do on your computer, to yourself, or to others, is none of my business nor my fault.
Open Regedit, and find the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
If it's not there already, create a new DWORD value named "IPEnableRouter". Set it's value to 1. Thankfully "1" is the same in decimal and in hex, so you don't have to worry about which one it's set to.
After that, reboot. That's all there is to it.
Just remember, though--routing is useless unless you've got two IP addresses to route between. They can be on the same card. Yes, there are occasions where that's actually needed--like in an IP range conversion. Been there, done that. The addresses can also be on different cards, or, better yet, one can be a VPN connection. Wow, I might have a use for that... :)
So, why not blog?
Routing in XP. It's still pretty simple to turn on, although not as easy as it was in NT 4 (check "Enable Routing"). There's a registry update necessary. You can find it pretty much anywhere on the net, including here:
Stupid little note: Changing the registry is dangerous stuff. I've heard of people losing limbs. Sprouting a second head is a very real possibility. You've been warned--anything you do on your computer, to yourself, or to others, is none of my business nor my fault.
Open Regedit, and find the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
If it's not there already, create a new DWORD value named "IPEnableRouter". Set it's value to 1. Thankfully "1" is the same in decimal and in hex, so you don't have to worry about which one it's set to.
After that, reboot. That's all there is to it.
Just remember, though--routing is useless unless you've got two IP addresses to route between. They can be on the same card. Yes, there are occasions where that's actually needed--like in an IP range conversion. Been there, done that. The addresses can also be on different cards, or, better yet, one can be a VPN connection. Wow, I might have a use for that... :)
Tuesday, February 10, 2004
Drumroll, please...
You know that Windows XP megadevice I've been yammering about? First one is installed. Of course, it's still in "Testing", but I've tested it enough to realize I'm really, really going to like this thing.
First, a little background (yeah, I've talked about this before). I work for a medium sized business with a number of sites. We've got a few sites that connect via IPSec VPNs back to the main office. It seems to be becoming our primary WAN solution. It actually does work pretty well.
Also, one of my pet projects has been to get some kind of file/print server out to each branch. My clients aren't very good at saving stuff to the server, and who can blame them--saving a big spreadsheet over the WAN link is painful sometimes. Add to that the nightmare that is printer administration right now (everyone prints directly to the IP address of printers), and you can see some of the benefits of getting a server to each site.
But why put two separate devices (server and VPN router) at each site? Seems like a waste to me. I went to Snapgear, who makes a VPN router that I really like (I've mentioned it before). It's actually a device running Embedded Linux. Seems like a no brainer to me to put a hard drive onto one of these, and, with Samba, turn it into a VPN/File/Print Server. No dice--they don't seem to have any plans to do such a logical, much needed product.
So, what do I turn to? Why, that Compaq Prolinea 2266 that I started off my blog with back in August, of course! Here's what I've got:
Prolinea 2266 running Windows XP
Two NICs (had to buy some used 3com NICs--the Netgear that came in the machine didn't take to well to having a twin)
Various registry updates to turn on routing within XP
Some (still in beta) batch files that detect the internet connection, and initiate a VPN connection (using PPTP, rather than IPSec, so it's client driven)
More (also beta) batch files that will connect to a dialup failover if the main internet connection fails (and then restart the VPN)
A DHCP Relay agent, which will pass DHCP requests on the remote network to our main DHCP server, for central administration
Print queues (using the ultra cool hierarchical queuing method that I mentioned in a previous post)
File shares
In short, everything that I want (well, other than QoS support, which I'm still looking into) in one device. The hardware we already own, and the software comes to around $200 (including the XP license). About the same price I'm paying for VPN routers now.
As I have time, I'm going to post more details on how this thing works, going in order of my list above (starting with the routing registry updates). I'll even be providing batch file source code, free of charge. I'm such a guy. :)
You know that Windows XP megadevice I've been yammering about? First one is installed. Of course, it's still in "Testing", but I've tested it enough to realize I'm really, really going to like this thing.
First, a little background (yeah, I've talked about this before). I work for a medium sized business with a number of sites. We've got a few sites that connect via IPSec VPNs back to the main office. It seems to be becoming our primary WAN solution. It actually does work pretty well.
Also, one of my pet projects has been to get some kind of file/print server out to each branch. My clients aren't very good at saving stuff to the server, and who can blame them--saving a big spreadsheet over the WAN link is painful sometimes. Add to that the nightmare that is printer administration right now (everyone prints directly to the IP address of printers), and you can see some of the benefits of getting a server to each site.
But why put two separate devices (server and VPN router) at each site? Seems like a waste to me. I went to Snapgear, who makes a VPN router that I really like (I've mentioned it before). It's actually a device running Embedded Linux. Seems like a no brainer to me to put a hard drive onto one of these, and, with Samba, turn it into a VPN/File/Print Server. No dice--they don't seem to have any plans to do such a logical, much needed product.
So, what do I turn to? Why, that Compaq Prolinea 2266 that I started off my blog with back in August, of course! Here's what I've got:
Prolinea 2266 running Windows XP
Two NICs (had to buy some used 3com NICs--the Netgear that came in the machine didn't take to well to having a twin)
Various registry updates to turn on routing within XP
Some (still in beta) batch files that detect the internet connection, and initiate a VPN connection (using PPTP, rather than IPSec, so it's client driven)
More (also beta) batch files that will connect to a dialup failover if the main internet connection fails (and then restart the VPN)
A DHCP Relay agent, which will pass DHCP requests on the remote network to our main DHCP server, for central administration
Print queues (using the ultra cool hierarchical queuing method that I mentioned in a previous post)
File shares
In short, everything that I want (well, other than QoS support, which I'm still looking into) in one device. The hardware we already own, and the software comes to around $200 (including the XP license). About the same price I'm paying for VPN routers now.
As I have time, I'm going to post more details on how this thing works, going in order of my list above (starting with the routing registry updates). I'll even be providing batch file source code, free of charge. I'm such a guy. :)
Monday, February 02, 2004
OK, the moves are done (we moved two branches into new buildings this month, which is part of the reason I've not discovered anything). So time to start sharing my vast wealth of knowledge with the world again.
Kinda tiny tidbit for this first one (trust me, I've got big stuff coming in a day or two): Why was my freezer broken? We've got a frost free upright freezer. Almost since we got it, it's been a little flaky. Twice a year, it seems to go nuts. The fan comes on, the condenser kicks on, and then the condenser kicks off. Fan keeps running, though. About a minute later, the condenser kicks on, and then off. This keeps up for days, until the freezer is about 40 degrees and everything has spoiled.
I've had a repair guy out 3 times on this. He's never found anything, because the problem seems to always occur on Friday, and by the time he gets out on Monday everything is working again. So the last time it happened I said "Screw the repair guy", and decided to fix it myself. A friend mentioned that problems like this could be the defrost heater or thermostat, so I located that and played around. I ran it without those devices for a while, and it seemed fine. By the time I was done playing, it was working again, so I hooked everything back up.
This weekend it started acting up again. So, knowing what I learned from last time, I removed the cover and bypassed the defrost thermostat--running the heater manually. The heater worked fine (it gets hot, and I've got the small burn on my finger to prove it). I then plugged everything back in, and waited for it to kick on again. When it did, it exhibited the same problems. So, next step--I disconnected the thermostat and printer, and put the cover back on. Within a minute, it was running normally again.
$150 worth of site visit costs from the repair guy, and it looks like my problem is a $10 part. I'm gonna order a new defrost thermostat today and find out for sure.
Kinda tiny tidbit for this first one (trust me, I've got big stuff coming in a day or two): Why was my freezer broken? We've got a frost free upright freezer. Almost since we got it, it's been a little flaky. Twice a year, it seems to go nuts. The fan comes on, the condenser kicks on, and then the condenser kicks off. Fan keeps running, though. About a minute later, the condenser kicks on, and then off. This keeps up for days, until the freezer is about 40 degrees and everything has spoiled.
I've had a repair guy out 3 times on this. He's never found anything, because the problem seems to always occur on Friday, and by the time he gets out on Monday everything is working again. So the last time it happened I said "Screw the repair guy", and decided to fix it myself. A friend mentioned that problems like this could be the defrost heater or thermostat, so I located that and played around. I ran it without those devices for a while, and it seemed fine. By the time I was done playing, it was working again, so I hooked everything back up.
This weekend it started acting up again. So, knowing what I learned from last time, I removed the cover and bypassed the defrost thermostat--running the heater manually. The heater worked fine (it gets hot, and I've got the small burn on my finger to prove it). I then plugged everything back in, and waited for it to kick on again. When it did, it exhibited the same problems. So, next step--I disconnected the thermostat and printer, and put the cover back on. Within a minute, it was running normally again.
$150 worth of site visit costs from the repair guy, and it looks like my problem is a $10 part. I'm gonna order a new defrost thermostat today and find out for sure.
Friday, January 16, 2004
OK, time to post something. Why? Well, because I like to hear myself type, that's why!
Actually, one of the things that I've been wanting to do is create a hierarchical printer structure between our Windows and Unix systems. Right now it's pretty flat--everyone and everything prints to the IP address of the printer (yeah, not even a DNS name!). Makes for nightmares in administraiton--I can't change the IP, I can't push out new drivers, and most importantly, I can't stop anyone from printing if there's something that needs to be high priority. We could be doing a check run and wind up with someone's shopping list printing out in the middle (on check paper).
So, the plan has been to push everything through the Windows server. Two problems there--first, I needed to use Samba to connect to the Windows print shares (not that there's any problem with Samba--it's just another piece of the puzzle), and secondly, AIX was really limited on how long the share name could be. This was the larger problem--I would wind up having to have two or more shares for the same printer, and the administration doesn't really get any easier that way.
A friend recommended that I try using LPR support in Windows ("Print Services for Unix"). By installing this, Unix systems can connect up to the printer object in Windows, shared or not. Problem 2 remains, though--Name limitation. I thought that if I could move documents through a heirarchical system of queues, I could resolve that. Turns out LPR support works great from Windows, as well. :)
I have a "top end" printer on our server that points directly to the IP of the printer. Unix prints to this printer. This one is not shared (so no confusion amongst users trying to install printers). There is a shared printer, with a descriptive name that fits our naming standard, installed as well. Instead of going to the IP of the printer, though, this goes to the LPR queue represented by the first "top end" printer. So, users print to the shared queue, and documents flow automatically into the LPR queue.
Now, for those "special" jobs like checks, I've got another top end LPR queue. Again, not shared--so it's just visible to the server and the Unix box. Special print jobs will be programatically sent to this queue. Before being sent, though, someone can pause the main top end queue. Jobs from either platform will simply pile up waiting to be printed, while jobs to the "special" queue will go right through.
Next step is to see if there's a way to programmatically pause a remote LPR queue from Unix, so that our ERP system could simply pause the Windows queue on its own. We'll see.
Actually, one of the things that I've been wanting to do is create a hierarchical printer structure between our Windows and Unix systems. Right now it's pretty flat--everyone and everything prints to the IP address of the printer (yeah, not even a DNS name!). Makes for nightmares in administraiton--I can't change the IP, I can't push out new drivers, and most importantly, I can't stop anyone from printing if there's something that needs to be high priority. We could be doing a check run and wind up with someone's shopping list printing out in the middle (on check paper).
So, the plan has been to push everything through the Windows server. Two problems there--first, I needed to use Samba to connect to the Windows print shares (not that there's any problem with Samba--it's just another piece of the puzzle), and secondly, AIX was really limited on how long the share name could be. This was the larger problem--I would wind up having to have two or more shares for the same printer, and the administration doesn't really get any easier that way.
A friend recommended that I try using LPR support in Windows ("Print Services for Unix"). By installing this, Unix systems can connect up to the printer object in Windows, shared or not. Problem 2 remains, though--Name limitation. I thought that if I could move documents through a heirarchical system of queues, I could resolve that. Turns out LPR support works great from Windows, as well. :)
I have a "top end" printer on our server that points directly to the IP of the printer. Unix prints to this printer. This one is not shared (so no confusion amongst users trying to install printers). There is a shared printer, with a descriptive name that fits our naming standard, installed as well. Instead of going to the IP of the printer, though, this goes to the LPR queue represented by the first "top end" printer. So, users print to the shared queue, and documents flow automatically into the LPR queue.
Now, for those "special" jobs like checks, I've got another top end LPR queue. Again, not shared--so it's just visible to the server and the Unix box. Special print jobs will be programatically sent to this queue. Before being sent, though, someone can pause the main top end queue. Jobs from either platform will simply pile up waiting to be printed, while jobs to the "special" queue will go right through.
Next step is to see if there's a way to programmatically pause a remote LPR queue from Unix, so that our ERP system could simply pause the Windows queue on its own. We'll see.
Tuesday, January 13, 2004
Man, 3 months. I'm a bad man.
Anyway, I swear some stuff is coming. I've got about a dozen projects about to reach critical mass. So, just to wet everyone's whistle, here's some of the stuff I'm gonna be posting:
1. Creating a site to site VPN using PPTP and a Windows XP Server/Router.
2. Setting up our VoIP phone system
3. Group Policy and Login Script magic
4. Buying real estate for no money down!
Maybe not 4. :)
Anyway, I swear some stuff is coming. I've got about a dozen projects about to reach critical mass. So, just to wet everyone's whistle, here's some of the stuff I'm gonna be posting:
1. Creating a site to site VPN using PPTP and a Windows XP Server/Router.
2. Setting up our VoIP phone system
3. Group Policy and Login Script magic
4. Buying real estate for no money down!
Maybe not 4. :)
Monday, October 20, 2003
No, I haven't forgotten that I've got a blog. In fact, I've got a ton of stuff to put in here. But I've just been way too busy.
A quick note, though. Something I learned the hard way this morning. Both DHCP and WINS don't seem to like sitting on a box that has a NIC with multiple IP addresses. Most of the time, they seem to bind to whichever address is the primary, but it's not 100%.
I had a server that was soley a PDC with DNS, DHCP, and WINS. I've been wanting to get it out of the rack (mainly for the space). I've got a perfectly capable Dell server that I moved the services to.
But, since so many of my clients have static IP addresses (grumble), I needed to ensure that the IP of the old server still would resolve names. Easy enough--just add the address to the adapter on the newer server, right? That worked great for DNS, but WINS and DHCP choked. They both bound to the primary address only.
So, if you ever have need to move those services to a machine with multiple IPs on a single card, check the services after the fact to make sure that they bound to the card you were expecting.
A quick note, though. Something I learned the hard way this morning. Both DHCP and WINS don't seem to like sitting on a box that has a NIC with multiple IP addresses. Most of the time, they seem to bind to whichever address is the primary, but it's not 100%.
I had a server that was soley a PDC with DNS, DHCP, and WINS. I've been wanting to get it out of the rack (mainly for the space). I've got a perfectly capable Dell server that I moved the services to.
But, since so many of my clients have static IP addresses (grumble), I needed to ensure that the IP of the old server still would resolve names. Easy enough--just add the address to the adapter on the newer server, right? That worked great for DNS, but WINS and DHCP choked. They both bound to the primary address only.
So, if you ever have need to move those services to a machine with multiple IPs on a single card, check the services after the fact to make sure that they bound to the card you were expecting.
Wednesday, September 03, 2003
Dear Lord, give me bandwidth
Why did the chicken cross the road? Because they had broadband available on the other side. I've been working on setting up our newest branch. Our current approach is DSL and a VPN router to connect to our main site. The DSL provider told me 3 weeks was normal install time--but then most of the eastern seaboard lost power. Whether it's true or not I don't know, but our install date has been bumped because of the power outage. And we needed to go live Sept. 2.
I've been working on a failover plan for our other branches involving a Snapgear router. Most Snapgears support both broadband and dialup (using an external modem). The goal was to get a Snapgear to our remote sites, and have them configured to dial up to the internet if the DSL connection went down. I'd done some testing. Then Sept. 2 rolled around, and it got thrown right into prime time. And what a spectacular failure it was.
Part of it was the fact that we took a bunch of guys who are used to the 100mb connection in their offices, and put them out remotely for a day. It's amazing how quickly you can fill up a 44kbs pipe. But even with one person connected, I still had problems. Telnet sessions (which we depend on) dropped sporatically. Most network resources were fine, but those stateful connections got to be a real pain.
The wierd part is that I remember using Telnet back in college over 9600kbs dialup on static-y dorm room phone lines. It always seemed pretty forgiving. But it wasn't yesterday. I'm still not sure if it's the additional overhead that the IPSEC tunnel adds to the mix, or if it's just plain line speed. But we were sitting around yesterday trying to figure out a way to get a long range wireless connection to work through a hill and a number of highways.
Thankfully I spoke with our DSL "engineer" this morning, and while he doesn't have any specific dates yet, he feels it should be very soon, and he's working for us to try to get the install moved up in the priority list. Until that's in, I'm laying low trying to avoid the bullets aimed in my direction...
Why did the chicken cross the road? Because they had broadband available on the other side. I've been working on setting up our newest branch. Our current approach is DSL and a VPN router to connect to our main site. The DSL provider told me 3 weeks was normal install time--but then most of the eastern seaboard lost power. Whether it's true or not I don't know, but our install date has been bumped because of the power outage. And we needed to go live Sept. 2.
I've been working on a failover plan for our other branches involving a Snapgear router. Most Snapgears support both broadband and dialup (using an external modem). The goal was to get a Snapgear to our remote sites, and have them configured to dial up to the internet if the DSL connection went down. I'd done some testing. Then Sept. 2 rolled around, and it got thrown right into prime time. And what a spectacular failure it was.
Part of it was the fact that we took a bunch of guys who are used to the 100mb connection in their offices, and put them out remotely for a day. It's amazing how quickly you can fill up a 44kbs pipe. But even with one person connected, I still had problems. Telnet sessions (which we depend on) dropped sporatically. Most network resources were fine, but those stateful connections got to be a real pain.
The wierd part is that I remember using Telnet back in college over 9600kbs dialup on static-y dorm room phone lines. It always seemed pretty forgiving. But it wasn't yesterday. I'm still not sure if it's the additional overhead that the IPSEC tunnel adds to the mix, or if it's just plain line speed. But we were sitting around yesterday trying to figure out a way to get a long range wireless connection to work through a hill and a number of highways.
Thankfully I spoke with our DSL "engineer" this morning, and while he doesn't have any specific dates yet, he feels it should be very soon, and he's working for us to try to get the install moved up in the priority list. Until that's in, I'm laying low trying to avoid the bullets aimed in my direction...
Saturday, August 16, 2003
If they want it, they can turn it on...
Oh, I forgot something (or maybe I'm just looking for excuses to stay up even later). About my "performance tuning" on those Prolineas: I'm sure you're asking "How can you make sure that, when a new user logs in, they are set to "Performance" as well?" I understand your curiosity. After all, when a new user logs into a machine, and they don't have a roaming profile (we don't use them yet), their default settings are to have all the fancy colorful stuff that XP has. I wish I could change that default...
Well, duh, I wouldn't be talking about this if you couldn't. Here's my main "user related" tasks when setting up a new machine (unless I work from an image--which I'm not doing just yet):
1. Setup the machine in a workgroup. It's just easier this way--trust me.
2. Create one extra user (in addition to Administrator). Log in as this user when the time comes.
3. In Control Panel|Users, turn off the "Welcome Screen". It'll get turned off when you add the system to the domain anyway, and it makes the following steps a lot easier.
4. Setup your current user (we'll just call it "User1") the way you want. Themes, Start menu, desktop, background image (or lack thereof), everything. If you want to use the "Send To" trick from my first post, set this up as well for "User1".
5. Log out, and log in as Administrator. Notice how everything is so Windows XP-y, and nothing like you had setup "User1".
6. Go into My Computer properites, to the "Advanced" tab, and click the settings button for "User Profiles"
7. Select your "User1" profile. Click the "Copy To" button. Enter "C:\Documents and Settings\Default User" (of course, if your documents and settings folder is somewhere else, change this path accordingly). Hit OK a couple of times. This copies the "User1" profile--which you setup exactly how you like it--to the "Default User" profile.
At this point, you could add the machine to the domain and be happy. But I like to do a couple more steps:
8. Log out, and log in as User1.
9. Go into My Computer properties, Advanced, and "Settings" in User Profiles. Select the "Administrator" profile, and click "Delete". This deletes the current Administrator profile (not the user ID).
10. Log out, and log in as Administrator. Note how it's your "default" profile now. Cool, huh?
11. Go back to that User Profile settings screen (again), and delete the "User1" profile. Also, go into Users in Control Panel and delete the User1 user. Don't want a local user with Admin rights that doesn't have a password.
12. Now add the machine to the domain.
One thing I haven't been able to try yet is to take a "Default User" profile directory from one machine, and put it on another. Seems like it should work--after all, this is all that Roaming Profiles do. If it does work, then I could have my "Gold" default profile on the network, and just copy it to a machine--effectively skipping pretty much every step above. I could also publish updates to the "default" profile, at the same time deleting all other profiles, to force updates out. But this would just tick off clients--imagine your desktop and start menu just getting wiped out and replaced every couple months.
Oh, I forgot something (or maybe I'm just looking for excuses to stay up even later). About my "performance tuning" on those Prolineas: I'm sure you're asking "How can you make sure that, when a new user logs in, they are set to "Performance" as well?" I understand your curiosity. After all, when a new user logs into a machine, and they don't have a roaming profile (we don't use them yet), their default settings are to have all the fancy colorful stuff that XP has. I wish I could change that default...
Well, duh, I wouldn't be talking about this if you couldn't. Here's my main "user related" tasks when setting up a new machine (unless I work from an image--which I'm not doing just yet):
1. Setup the machine in a workgroup. It's just easier this way--trust me.
2. Create one extra user (in addition to Administrator). Log in as this user when the time comes.
3. In Control Panel|Users, turn off the "Welcome Screen". It'll get turned off when you add the system to the domain anyway, and it makes the following steps a lot easier.
4. Setup your current user (we'll just call it "User1") the way you want. Themes, Start menu, desktop, background image (or lack thereof), everything. If you want to use the "Send To" trick from my first post, set this up as well for "User1".
5. Log out, and log in as Administrator. Notice how everything is so Windows XP-y, and nothing like you had setup "User1".
6. Go into My Computer properites, to the "Advanced" tab, and click the settings button for "User Profiles"
7. Select your "User1" profile. Click the "Copy To" button. Enter "C:\Documents and Settings\Default User" (of course, if your documents and settings folder is somewhere else, change this path accordingly). Hit OK a couple of times. This copies the "User1" profile--which you setup exactly how you like it--to the "Default User" profile.
At this point, you could add the machine to the domain and be happy. But I like to do a couple more steps:
8. Log out, and log in as User1.
9. Go into My Computer properties, Advanced, and "Settings" in User Profiles. Select the "Administrator" profile, and click "Delete". This deletes the current Administrator profile (not the user ID).
10. Log out, and log in as Administrator. Note how it's your "default" profile now. Cool, huh?
11. Go back to that User Profile settings screen (again), and delete the "User1" profile. Also, go into Users in Control Panel and delete the User1 user. Don't want a local user with Admin rights that doesn't have a password.
12. Now add the machine to the domain.
One thing I haven't been able to try yet is to take a "Default User" profile directory from one machine, and put it on another. Seems like it should work--after all, this is all that Roaming Profiles do. If it does work, then I could have my "Gold" default profile on the network, and just copy it to a machine--effectively skipping pretty much every step above. I could also publish updates to the "default" profile, at the same time deleting all other profiles, to force updates out. But this would just tick off clients--imagine your desktop and start menu just getting wiped out and replaced every couple months.
Mmmm...frozen Mt. Dew.
Had too much of it at the theater tonight, so here I sit at 1am typing away. Not a whole lot of stuff today. Figure I'll share a couple of little tidbits:
IPSEC VPN Tunnels don't pass Multicast packets. Who cares? Well, if you've got a client on the far side of a VPN telnetting to an AIX (or maybe any Unix) box on your end, and he/she leaves the session alone for a while, it disconnects them. It seems that if the session is just sitting there (no keyboard activity to let the server know that the client is still alive), and if it doesn't respond to enough "Are you out there" queries from the server, the server will toast the connection. AIX seems to send these packets out as a multicast, which doesn't go through our VPN. No way around it, either, without setting up routers internally on each network to create a GRE tunnel between the sites. Bummer.
Installed XP on another of our Compaq Prolinea 2266s today. Put a little extra RAM in those (I bumped the XP ones up to 128MB), and XP runs really well. I was quite surprised. I usually cut down on the color depth (shared video RAM, so the lower your color depth, the more system RAM you've got), and then change the visual settings to the "Performance" option. As long as our application requirements don't change, I think that XP could give us another two years out of these systems. Well, if the hardware holds out, that is.
I've got a plan for them, though, even when I start replacing them. Most of our sites use 64kbs leased lines to connect back "home". With MSBlast out, I've been trying to figure out a good way to get patches and updates out to a site, so they are easily accessible to users at that site without "downloading" it over the slow line multiple times. My hope is to put one of these old machines (running XP with 128MB RAM and possibly a set of mirrored 4GB hard drives) at each site. It'll have a single shared folder that I can run an automated cleaning process on occasionally. I can also use it as a print server--installing printers is a huge pain right now, because I have to track down the IP address of the printer, setup a port, find the driver, etc. If I create a print queue in XP (works in 2K as well), I can embed the drivers for various versions of Windows, and have a single stop for installing printers.
As a continuation of yesterday's post (well, really Thursday's post), thought I'd pass on some more coolness with PSTools. I installed XP SP1A onto a system today. Without touching the system. I copied the update to the system to be patched, and ran it on that system using PSTools. It took over an hour, but I think that was just system speed (these are something like 266mhz Cyrix chips, after all). I kept an eye on network traffic, and after the transfer of the SP to the destination system, there was no other network traffic. I'm definately approaching Network Admin Nirvana here. I think I'm gonna have to step into 1997, though, and write this into a VBScript. I want to do a batch file--I really do. But I can't keep ignoring the future. Now if you'll excuse me, I have to go fire up my 8 track player.
Had too much of it at the theater tonight, so here I sit at 1am typing away. Not a whole lot of stuff today. Figure I'll share a couple of little tidbits:
IPSEC VPN Tunnels don't pass Multicast packets. Who cares? Well, if you've got a client on the far side of a VPN telnetting to an AIX (or maybe any Unix) box on your end, and he/she leaves the session alone for a while, it disconnects them. It seems that if the session is just sitting there (no keyboard activity to let the server know that the client is still alive), and if it doesn't respond to enough "Are you out there" queries from the server, the server will toast the connection. AIX seems to send these packets out as a multicast, which doesn't go through our VPN. No way around it, either, without setting up routers internally on each network to create a GRE tunnel between the sites. Bummer.
Installed XP on another of our Compaq Prolinea 2266s today. Put a little extra RAM in those (I bumped the XP ones up to 128MB), and XP runs really well. I was quite surprised. I usually cut down on the color depth (shared video RAM, so the lower your color depth, the more system RAM you've got), and then change the visual settings to the "Performance" option. As long as our application requirements don't change, I think that XP could give us another two years out of these systems. Well, if the hardware holds out, that is.
I've got a plan for them, though, even when I start replacing them. Most of our sites use 64kbs leased lines to connect back "home". With MSBlast out, I've been trying to figure out a good way to get patches and updates out to a site, so they are easily accessible to users at that site without "downloading" it over the slow line multiple times. My hope is to put one of these old machines (running XP with 128MB RAM and possibly a set of mirrored 4GB hard drives) at each site. It'll have a single shared folder that I can run an automated cleaning process on occasionally. I can also use it as a print server--installing printers is a huge pain right now, because I have to track down the IP address of the printer, setup a port, find the driver, etc. If I create a print queue in XP (works in 2K as well), I can embed the drivers for various versions of Windows, and have a single stop for installing printers.
As a continuation of yesterday's post (well, really Thursday's post), thought I'd pass on some more coolness with PSTools. I installed XP SP1A onto a system today. Without touching the system. I copied the update to the system to be patched, and ran it on that system using PSTools. It took over an hour, but I think that was just system speed (these are something like 266mhz Cyrix chips, after all). I kept an eye on network traffic, and after the transfer of the SP to the destination system, there was no other network traffic. I'm definately approaching Network Admin Nirvana here. I think I'm gonna have to step into 1997, though, and write this into a VBScript. I want to do a batch file--I really do. But I can't keep ignoring the future. Now if you'll excuse me, I have to go fire up my 8 track player.
Thursday, August 14, 2003
I do not speak to people directly. If you need me, please send a page to me as I sit in my ivory tower...
Well, MSBLAST got into the network today. Our salesmen all have laptops, and they regularly dial up to their ISP with them. One of them probably got the worm before we got his laptop patched, and today was the first time he'd plugged it into our network. I wasn't too worried about patching internal systems, because my hope was that if I kept the gates secure, the invaders could never harm the peasants inside (yeah, I love to compare corporate networks to feudal kingdoms. :)).
I had to scramble a little this afternoon to get everything cleaned up, but I'm glad I had the experience. Why? 'Cause I found something uber-cool, that's why. http://www.sysinternals.com/ntw2k/freeware/pstools.shtml is a bunch of freeware process management tools for Windows NT and greater. They give me, as an admin, the ability to remotely start, stop, list, etc. processes on another machine.
So how does this tie back to MSBlast? This worm is pretty simple to detect--if it infects you, you wind up with an msblast.exe file somewhere on your system. I could do a quick dir \\remotesystem\c$ /s to see if it's there. Problem is, if it's there, then it's probably running as well. You can't delete it if it's in use. So, pskill \\remotesystem msblast.exe shuts it off. Then I can delete it. Then I can use psexec \\remotesystem regedit regfile.reg to modify the registry, removing the item that MSBlast puts in there.
But it gets better. I can run the patch on the remote system as well. I can copy the patch to the remote system (I like to name it patch.exe, so it's easy to find later, and replaced if I roll out another patch), and then run psexec \\remotesystem patch.exe /u /z /q. The parms are pretty standard for Microsoft updates: /u runs it in unattended mode (this might be redudant with /q), /z prevents it from rebooting, and /q runs it without a user interface. After that returns, I can run psshutdown \\remotesystem -r to reboot the remote system.
Being the lazy guy that I am, I've put all this into a batch file that I can simply pass a system name to. My ultimate plan is to pick one evening a month that I ask everyone to leave their systems on, but logged off. I create a list of system names, pass it to the batch file, and viola, everyone is patched and rebooted come morning.
Well, MSBLAST got into the network today. Our salesmen all have laptops, and they regularly dial up to their ISP with them. One of them probably got the worm before we got his laptop patched, and today was the first time he'd plugged it into our network. I wasn't too worried about patching internal systems, because my hope was that if I kept the gates secure, the invaders could never harm the peasants inside (yeah, I love to compare corporate networks to feudal kingdoms. :)).
I had to scramble a little this afternoon to get everything cleaned up, but I'm glad I had the experience. Why? 'Cause I found something uber-cool, that's why. http://www.sysinternals.com/ntw2k/freeware/pstools.shtml is a bunch of freeware process management tools for Windows NT and greater. They give me, as an admin, the ability to remotely start, stop, list, etc. processes on another machine.
So how does this tie back to MSBlast? This worm is pretty simple to detect--if it infects you, you wind up with an msblast.exe file somewhere on your system. I could do a quick dir \\remotesystem\c$ /s to see if it's there. Problem is, if it's there, then it's probably running as well. You can't delete it if it's in use. So, pskill \\remotesystem msblast.exe shuts it off. Then I can delete it. Then I can use psexec \\remotesystem regedit regfile.reg to modify the registry, removing the item that MSBlast puts in there.
But it gets better. I can run the patch on the remote system as well. I can copy the patch to the remote system (I like to name it patch.exe, so it's easy to find later, and replaced if I roll out another patch), and then run psexec \\remotesystem patch.exe /u /z /q. The parms are pretty standard for Microsoft updates: /u runs it in unattended mode (this might be redudant with /q), /z prevents it from rebooting, and /q runs it without a user interface. After that returns, I can run psshutdown \\remotesystem -r to reboot the remote system.
Being the lazy guy that I am, I've put all this into a batch file that I can simply pass a system name to. My ultimate plan is to pick one evening a month that I ask everyone to leave their systems on, but logged off. I create a list of system names, pass it to the batch file, and viola, everyone is patched and rebooted come morning.
Wednesday, August 13, 2003
XP on a four year old computer. I must be nuts. Anyway, this is my first post, so at some point I'm gonna have to backtrack and get some other tips typed up. But for today, just a simple one that everyone else in the world probably already knows.
Quite often I have a client ask me "How do I get this to start up when I log in?" I usually shudder--every admin's worst nightmare is that machine that you come to that has every app in the sun starting on logon. The one where the client often says "Yeah, I log in and then go get my morning coffee--it's usually done by the time I get back." But most clients don't really understand why we hate this, so they stay pretty insistent.
The shell update in Windows 98 made this a little easier--being able to right click on stuff in the Start Menu meant that we could copy a shortcut to the clipboard, and then open the startup folder and paste it. But wouldn't be easier to just tell someone "Just right click on the icon, and hit "Startup"?" Well, at least for XP (and if you aren't using XP, then upgrade!), I've found a way to do this, using the "Send To" feature.
Your "Sent To" folder is in (by default) C:\Documents and Settings\. The folder contains shortcuts to applications or folders that you want to send files to. It's a piece of cake to add to your "Send To" menu--just put a new shortcut into this folder. So, if you want to be able to send stuff to your "Startup" group, just find your Startup group under C:\Documents and Settings\\Start Menu, and do a Right Click Drag to the Send To folder--choosing "Create Shortcut Here" when asked. Now you can right click on any icon in your Start Menu, select Send To, and send it right into the Startup Group.
"Wow, man I LOVE this. I want to do it on every machine. I want it for every user. But I'm lazy and don't want to manually add it each time!" Don't worry--I'm lazy too. So I've got a solution. Create a shortcut which points to "%userprofile%\Start Menu\Startup". %userprofile% is the environment variable that points to the folder that your user profile is in. In a login script, copy this .lnk file to "%userprofile%\Send To".
"Man that worked great. But I don't want to leave it in the login script--how do I make sure it's available when someone new logs into a machine?" The Default User profile is your friend--copy your .lnk file you created above into the C:\Documents and Settings\Default User\Sent To folder. Now any time a new profile gets created on that box, the shortcut is put into it's Sent To folder.
Quite often I have a client ask me "How do I get this to start up when I log in?" I usually shudder--every admin's worst nightmare is that machine that you come to that has every app in the sun starting on logon. The one where the client often says "Yeah, I log in and then go get my morning coffee--it's usually done by the time I get back." But most clients don't really understand why we hate this, so they stay pretty insistent.
The shell update in Windows 98 made this a little easier--being able to right click on stuff in the Start Menu meant that we could copy a shortcut to the clipboard, and then open the startup folder and paste it. But wouldn't be easier to just tell someone "Just right click on the icon, and hit "Startup"?" Well, at least for XP (and if you aren't using XP, then upgrade!), I've found a way to do this, using the "Send To" feature.
Your "Sent To" folder is in (by default) C:\Documents and Settings\
"Wow, man I LOVE this. I want to do it on every machine. I want it for every user. But I'm lazy and don't want to manually add it each time!" Don't worry--I'm lazy too. So I've got a solution. Create a shortcut which points to "%userprofile%\Start Menu\Startup". %userprofile% is the environment variable that points to the folder that your user profile is in. In a login script, copy this .lnk file to "%userprofile%\Send To".
"Man that worked great. But I don't want to leave it in the login script--how do I make sure it's available when someone new logs into a machine?" The Default User profile is your friend--copy your .lnk file you created above into the C:\Documents and Settings\Default User\Sent To folder. Now any time a new profile gets created on that box, the shortcut is put into it's Sent To folder.
Subscribe to:
Posts (Atom)