I wanted to do some logging of network interface usage on some of our switches so I thought I'd setup Cacti and give it a try. Why Cacti, well I had used it before (years ago) and thought I'd use it again.
Where did I start? I thought a linux box my be the easiest way to get it going. I also thought if I ran into problems help would be easier to find for a linux box than a Windows box also. So I went to Ubuntu's website and grabbed the latest LTS Server iso (which happens to be 12.04 Precise Pangolin). Then I picked up a flash drive and used unetbootin to load the iso on the drive. Waited for it to finish, then pulled the drive out and attempted to boot the system from the flash drive.
I noticed the boot loader mentioned loading some BSD files which I thought was rather odd, but I went on working on something else and waited for it to finish booting up. I checked the boot screen and it wasn't a Ubuntu install, it was an install screen for an appliance that I had recently updated using that same flash drive. Apparently UNetbootin didn't overwrite the other installer correctly. The plan was to just format the drive and try again. It seems nothing goes as easily as it should. Windows only recognizes the 4gb flash drive as a 28mb drive. Great, the appliance installer must have partitioned the drive and Windows can't read it correctly. So I downloaded BOOTICE from http://bbs.ipauly.com/ to clear off the partitions and reformat the drive.
After doing that I, I then re-ran UNetbootin and loaded the iso back on the drive. Did I mention that nothing seems to go as easy as it should? I picked USB Boot out of the boot menu on the computer and bam, an immediate "Boot Failed" message. Great...what's wrong now? The drive had been a little slow to write to, maybe it had finally died. Being in the computer business it seems there's always another flash drive lying around so I looked until I found a 1gb drive. That doesn't sound like much but it's plenty for a Ubuntu installation.
Third time's the charm, right? Run through UNetbootin to copy the iso to the flash drive, then boot the computer, and finally... a Ubuntu install screen.
This is all pretty basic stuff on the Ubuntu install. I went through and did pick to use the entire drive and install LVM. When it asked about what applications to installed I picked the LAMP option (that's Linux Apache MySQL PHP in case you wondered). There are more guides for installing Ubuntu than you can shake a stick at so I wont cover that here.
After a couple of false starts there I finally got Ubuntu installed on the machine. To get Cacti installed is pretty easy. I did a sudo apt-get install cacti and it installed cacti and all the dependencies and loaded right into the cacti setup.
Setting up cacti is pretty straight forward. Here's a link install-and-configure-cacti-monitoring-tool-in-ubuntu-9-10-karmic-server.html to a guide that's complete with screenshots. This one's pretty close to what I saw. The only difference I found is that the RRDTools version that comes with Ubuntu 12.04 is 1.4 instead of version 1.3 as indicated in the guide. Also, I haven't gotten around to chance the Spine setup as indicated towards the end of the guide and so far mine is working fine.
At this point you should have your Ubuntu server up and running with Cacti installed and also running.
Since it seems this post is getting a little long, I think I'll break it into two posts. Check back in for the second part.
Here's the link for that second part.
http://practicalschooltech.blogspot.com/2013/10/my-aventures-in-installing-cacti-part-2.html
Thursday, October 24, 2013
Tuesday, October 22, 2013
Assigning local rights through Group policy and making it work
Trouble getting local computer rights assigned through group policy? Have you read all the articles that tell you to edit the GPO and assign the rights? Are they still not showing up on your Windows XP machines? That's the trouble I ran into.
Before I get too far into this. Let's go back to begining. We made the switch to from a Novell network (Netware servers, eDirectory, ZDM, iPrint and the Novell Client) to Microsoft network (Active Directory). After the switch we needed someway to manage the rights that local users have on machines. In the past we used ZENworks and when users logged into their computers (through the Novell Client), Zen would pick that up and create a local user for that person with the rights that we assigned and then seamlessly log the user into that account. When using AD it doesn't work the same. The users just log into the machine, because the machine is in the domain they don't get (or need) a local account. Which is great, except that some of the people need to be administrators or power users. I know I could go through group policy and assign specific rights, but we don't need that granular of control. Just making them members of the local groups is good enough.
Now there's a couple of ways to get them in as member of a group. The original way to do it with group policy was to use the Restricted Groups feature. Doing it that way makes sure people are members of the group and that only those people are members of the group. That's nice for some environments, but we don't need that level of control. For us, all we need is to add people to groups from time to time. There's a new way to do just that. Well, I say new way, it's been around for 5 or 6 years. Its through an addon to group policy called Client Side Extensions. Microsoft bought out a company that was doing some neat group policies addons and then MS built it into Windows and released it free of charge for all to use. But that's a story for a different day, the point is that I wanted to assign the group membership using this part of gorup policies. So I started doing my homework. I read a lot of posts about using them and I dug through the MS documentation. It seemed pretty straight forward, I made my own policy, I assigned it, then I tested it, and then I found out it didn't work.
What had I missed? I went back through and double-checked everything. And then I tested agian.... nothing. And I tested again and again. It just wasn't working for me. As it so often happens I got pulled away to work on something else, but I had left the policies applied. They weren't working but didn't appear to breaking anything, so what did it matter, right? A few days passed and then I got back to working on this problem again and guess what, it worked. Right... it worked. Go figure. What had changed? I went back through everything and the only thing that had changed was my test machine. Lesson learned, if at first you don't succeed, try a different test machine.
Now that I knew the problem was in my machine, I just had to figure out what exactly it was. Back to the internet to see what pieces made these group policy extensions tick. What I found was two different Windows update that make it happen.
The first one is KB915865 which covers XMLLite. If you're running XP 32-bit here's that download link so you don't have to go looking for it http://www.microsoft.com/en-us/download/details.aspx?id=13978
The second update is KB943729 which covers the actual new Group Policy preferences. If you're running XP 32-bit here's that download link as well, http://www.microsoft.com/en-us/download/details.aspx?id=3628
Now that you know what you need to you need to figure out what systems need it right? Well the fastest way for me to tell if the computer is working right is to use NET LOCALGROUP ADMINISTRATORS at a command prompt. We've got a couple of accounts that we add as local admins on all machines, if the only thing listed on that command is a "MyDomain\Domain Admins" then I know I'm missing one of the updates listed above.
How about a quick way to tell which update you're missing? Check the C:\WINDOWS\SYSTEM32 folder. The XMLLite update installs an XMLLITE.DLL file, if it's there, then the update has been installed (of course it could be corrupt or not registered correctly). To see if Group Policy preferences update has been installed look for a GPPREFCL.DLL file.
So one command to see if it's working.
NET LOCALGROUP ADMINISTRATORS
And two commands to figure out what you're missing.
DIR C:\WINDOWS\SYSTEM32\XMLLITE.DLL
DIR C:\WINDOWS\SYSTEM32\GPPREFCL.DLL
After you install the updates just let the machine reboot and log back in. I have noticed that on the faster machines if you log back in after the reboot with a machine that's supposed to be getting admin rights that it doesn't get the rights on first log in. If you check the group memberships it shows up rights but you don't have admin rights. I think what's happening is that the system is logging the account in before the group policies have time to finish applying and since the memberships haven't assigned when the account logs in it doesn't get the rights. By time you can check the memberships it shows up correctly, but you don't have the rights because the weren't there at login. The fix is to just log out and back in and then you'll have the rights. The irony is that it seems like some of our slower machines are not affected by this, I guess the policy has time to finish applying before it actually starts processing the login. Who knows? If all it takes is a log off and back on, I'll take it.
Now there's a couple of ways to get them in as member of a group. The original way to do it with group policy was to use the Restricted Groups feature. Doing it that way makes sure people are members of the group and that only those people are members of the group. That's nice for some environments, but we don't need that level of control. For us, all we need is to add people to groups from time to time. There's a new way to do just that. Well, I say new way, it's been around for 5 or 6 years. Its through an addon to group policy called Client Side Extensions. Microsoft bought out a company that was doing some neat group policies addons and then MS built it into Windows and released it free of charge for all to use. But that's a story for a different day, the point is that I wanted to assign the group membership using this part of gorup policies. So I started doing my homework. I read a lot of posts about using them and I dug through the MS documentation. It seemed pretty straight forward, I made my own policy, I assigned it, then I tested it, and then I found out it didn't work.
What had I missed? I went back through and double-checked everything. And then I tested agian.... nothing. And I tested again and again. It just wasn't working for me. As it so often happens I got pulled away to work on something else, but I had left the policies applied. They weren't working but didn't appear to breaking anything, so what did it matter, right? A few days passed and then I got back to working on this problem again and guess what, it worked. Right... it worked. Go figure. What had changed? I went back through everything and the only thing that had changed was my test machine. Lesson learned, if at first you don't succeed, try a different test machine.
Now that I knew the problem was in my machine, I just had to figure out what exactly it was. Back to the internet to see what pieces made these group policy extensions tick. What I found was two different Windows update that make it happen.
The first one is KB915865 which covers XMLLite. If you're running XP 32-bit here's that download link so you don't have to go looking for it http://www.microsoft.com/en-us/download/details.aspx?id=13978
The second update is KB943729 which covers the actual new Group Policy preferences. If you're running XP 32-bit here's that download link as well, http://www.microsoft.com/en-us/download/details.aspx?id=3628
Now that you know what you need to you need to figure out what systems need it right? Well the fastest way for me to tell if the computer is working right is to use NET LOCALGROUP ADMINISTRATORS at a command prompt. We've got a couple of accounts that we add as local admins on all machines, if the only thing listed on that command is a "MyDomain\Domain Admins" then I know I'm missing one of the updates listed above.
How about a quick way to tell which update you're missing? Check the C:\WINDOWS\SYSTEM32 folder. The XMLLite update installs an XMLLITE.DLL file, if it's there, then the update has been installed (of course it could be corrupt or not registered correctly). To see if Group Policy preferences update has been installed look for a GPPREFCL.DLL file.
So one command to see if it's working.
NET LOCALGROUP ADMINISTRATORS
And two commands to figure out what you're missing.
DIR C:\WINDOWS\SYSTEM32\XMLLITE.DLL
DIR C:\WINDOWS\SYSTEM32\GPPREFCL.DLL
After you install the updates just let the machine reboot and log back in. I have noticed that on the faster machines if you log back in after the reboot with a machine that's supposed to be getting admin rights that it doesn't get the rights on first log in. If you check the group memberships it shows up rights but you don't have admin rights. I think what's happening is that the system is logging the account in before the group policies have time to finish applying and since the memberships haven't assigned when the account logs in it doesn't get the rights. By time you can check the memberships it shows up correctly, but you don't have the rights because the weren't there at login. The fix is to just log out and back in and then you'll have the rights. The irony is that it seems like some of our slower machines are not affected by this, I guess the policy has time to finish applying before it actually starts processing the login. Who knows? If all it takes is a log off and back on, I'll take it.
Monday, October 21, 2013
Changing XP Wallpaper from ZENworks
I mentioned in a previous post ( Changing XP Background (Wallpaper) Images ) about creating a ZENworks application to reset the background or wallpaper image. But I should have tested my app more thoroughly as it took a little tinkering to get it working. ZENworks veterans probably wouldn't have made this mistake, but as I'm new to version 11 (made the jump from 7) I did make the mistake.
The most common bundle action that I use is one of the "Launch" actions, whether it's an executable or an installer. Those actions by default run as the logged in user. What I found out is that "Registry Edit" actions by default execute as the System account. Which is probably great for making sure that the settings apply, but that's not so great when you're working in HKEY_CURRENT_USER. But there's an easy fix for that.
In the action properties just go to the Advanced tab and look at the "Run Action As" section. There's two ways to run it as System and as User. When you pick System there's one optional setting "Apply HKEY_CURRENT_USER changes to the logged in user's hive instead of .DEFAULT". The is fix is to check that box to make it work. Easy enough, right? I probably could have used the run as user option, but I tried checking the box worked and that fixed it, so I didn't try it with the user option set.
Here's picture so you can check that we're both looking at the same thing.
The most common bundle action that I use is one of the "Launch" actions, whether it's an executable or an installer. Those actions by default run as the logged in user. What I found out is that "Registry Edit" actions by default execute as the System account. Which is probably great for making sure that the settings apply, but that's not so great when you're working in HKEY_CURRENT_USER. But there's an easy fix for that.
In the action properties just go to the Advanced tab and look at the "Run Action As" section. There's two ways to run it as System and as User. When you pick System there's one optional setting "Apply HKEY_CURRENT_USER changes to the logged in user's hive instead of .DEFAULT". The is fix is to check that box to make it work. Easy enough, right? I probably could have used the run as user option, but I tried checking the box worked and that fixed it, so I didn't try it with the user option set.
Here's picture so you can check that we're both looking at the same thing.
Friday, October 18, 2013
Removing iPrint Printers and Uninstalling Novell iPrint Silently
Over this past summer break we changed our servers from old Netware 6.5 servers and we moved to new Windows Server 2012. At the same time we also changed from ZENworks Desktop Management 7 to ZENworks Configuration Managment 11. Since we had over 3000 machines across 10 campuses to change over and there was only 3 of us we did our best to move as fast as we could. In our haste we left the old Novell iPrint client (and iPrint printers) on the machines. So now that school is back in full spring and we're almost caught up we need to tackle the issue of removing all of those old printers that are confusing the teachers. We're not about to go back out and touch all of those machines again, that wouldn't be very practical. So we're going to do our best to automate the process.
How best to go about removing all of those old printers? You could write a script to loop through every printer on the local machine and check the name for ipp and remove it. That sounds like it would be a lot of steps and as anyone that has spent any amount of time working in IT knows, the more steps the more places for something to break. We wanted fast and simple. So we dug a little further and found that we can simply uninstall the iPrint client and it removes the iPrint printers with it. Keep in mind that this was an option for us because we are no longer going to be using iPrint.
So how best to uninstall the client? You can download an "installer" from Novell that uninstalls the client. Which is pretty cool. If you haven't messed with iPrint much you should check out Novell download section for it. They package several different installers to do a normal install, a silient install, a silent install with reboot, an uninstall.... (you get the picture, right?). These are handy, because they don't require any command line switches, and you can just give users the file they need and tell them to run it.
But I didn't want to have to distribute another file just to uninstall a program. So I dug through and found the uninstall command for iPrint. It turns out that it's a pretty straight forward command:
C:\WINDOWS\system32\iprint\setupipp.exe /uninstall
Which almost works for us by itself, but it's not silent. The user has to click that yes, they want to uninstall. We don't like manual steps around here. We don't like having to manually do something ourselves and sometimes simple things like clicking "Next" is a lot to ask of the users.
I did some Googling of the setupipp.exe command and really didn't come up with much. So I made an educated guess and tried a "/silent" switch. What do you know, it worked. So if you want to silently uninstall iPrint you can use this command
C:\WINDOWS\system32\iprint\setupipp.exe /uninstall /silent
A quick check shows that after the uninstall finishes the setupipp.exe file gets removed too. Which is great for us to use to automate. I put together a ZENworks bundle that looks for C:\WINDOWS\system32\iprint\setupipp.exe as a requirement (which means iPrint is still on the machine) and then it it runs C:\WINDOWS\system32\iprint\setupipp.exe /uninstall /silent to remove it. This works great, since it will only run on machines that have iPrint installed I can assign it to everyone without having to figure out first who needs it and who doesn't. And it doesn't require any work on the part of the user. I'd call that a win win situation.
Didn't I mention above that I went Googling for the command line switches for setupipp and didn't have any luck? Well I feel a bit dumb about it now. I went back and tried the "/?" option on setupipp and what do you know, it tells you all of the command line options. I guess there could still be something that's not documented, but it would have told me everything I would have needed to know. The lesson here is don't go searching the internet for help with the program itself will help you out with only two extra characters, a / and a ?.
Just in case you want to know what those options are and you don't happen to have iPrint installed anywhere. Here they are
---------------------------
iPrint Client Install
---------------------------
Installs or Uninstalls the Novell iPrint Client.
SETUPIPP [/S /R /U /L /?]
The default (no options) runs the install wizard.
/S Install/uninstall the client silently.
/R Restart the workstation when the install/uninstall is complete.
/U Uninstall the client from your workstation.
/? Display this help screen.
/L Install for an LDAP compliant environment (only unique usernames).
Don't have ZENworks but want to do this remotely? You can probably use PSEXEC to accomplish the same thing. Luckily, since you're running it remotely you don't even have to worry about checking for setupipp first. Just try to run it, PSEXEC will simply fail if iPrint isn't installed and the file isn't there. Questions about using PSEXEC, check out my other post http://practicalschooltech.blogspot.com/2013/10/remotely-installing-software_11.html
Wednesday, October 16, 2013
Changing XP Background (Wallpaper) Images
I know, I know, XP's old. But this is Practical School Tech and education is a little behind the times.
We had a couple of student systems where the students had set a background image by right-clicking images in IE and setting them as the wallpaper. Cute trick, right? But it's a pain to undo on a system where they don't get rights to the Display Properties page. The setting is stored per user (that way everyone can have their own) which is great unless your using a generic account that several students share. So how to undo it?
I though I'd start with the background image file. I did some Googling and most places said look in here
C:\Documents and Settings\Local Settings\Application Data\Microsoft\
But that isn't the right path, but it's close, it's really in
C:\Documents and Settings\Application Data\Microsoft\Internet Explorer
Or if you want to find it in a batch file (or just typing by hand), try this path instead
%AppData%\Microsoft\Internet Explorer
After finding the file I wanted to know where it is set in the registry. Since the image was set from inside IE file name was a very descriptive Internet Explorer Wallpaper.bmp. That's fairly unique, so I just searched through the registry for that file name. It turns out that path is stored in
HKEY_CURRENT_USER\Control Panel\Desktop
To clear the background image out I just blanked out the registry here.
HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper
After a reboot (or log off and log back on) the background image will be cleared and you'll be back to the pleasant soft blue.
But I didn't want to stop there. I wanted the change to go into affect immediately. I new when I changed the background through the Display Properties that the change happened right then. So that means there's a programmatic call somewhere that can make that happen. I had figured it was probably in some windows dll file and since wallpapers had been around so long that it was probably in one of the more common ones. A little more Googling and I came across this line
So I take all this information and roll it into a ZENworks bundle that deletes the key and then calls the UpdatePerUserSystemParameters to make it go into affect immediately.
We had a couple of student systems where the students had set a background image by right-clicking images in IE and setting them as the wallpaper. Cute trick, right? But it's a pain to undo on a system where they don't get rights to the Display Properties page. The setting is stored per user (that way everyone can have their own) which is great unless your using a generic account that several students share. So how to undo it?
I though I'd start with the background image file. I did some Googling and most places said look in here
C:\Documents and Settings\
But that isn't the right path, but it's close, it's really in
C:\Documents and Settings
Or if you want to find it in a batch file (or just typing by hand), try this path instead
%AppData%\Microsoft\Internet Explorer
After finding the file I wanted to know where it is set in the registry. Since the image was set from inside IE file name was a very descriptive Internet Explorer Wallpaper.bmp. That's fairly unique, so I just searched through the registry for that file name. It turns out that path is stored in
HKEY_CURRENT_USER\Control Panel\Desktop
To clear the background image out I just blanked out the registry here.
HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper
After a reboot (or log off and log back on) the background image will be cleared and you'll be back to the pleasant soft blue.
But I didn't want to stop there. I wanted the change to go into affect immediately. I new when I changed the background through the Display Properties that the change happened right then. So that means there's a programmatic call somewhere that can make that happen. I had figured it was probably in some windows dll file and since wallpapers had been around so long that it was probably in one of the more common ones. A little more Googling and I came across this line
%SystemRoot%\System32\RUNDLL32.EXE user32.dll,UpdatePerUserSystemParametersSo I take all this information and roll it into a ZENworks bundle that deletes the key and then calls the UpdatePerUserSystemParameters to make it go into affect immediately.
Friday, October 11, 2013
Remotely installing software
Ever need to install software remotely? Why not just fire up Remote Desktop (or VNC) and connect and install right? That works great if it's one machine you need to install software on. What happens when you have a lab full of machines that you need to install software on? You either need a lot of time or something that works faster than remotely installing it on each machine. So what are you options?
A login script. Great! But you have to make the script, associate with only the machines (or specific user) that you need it on, and then wait for someone to log into the machine. Or remote the machine and log in yourself, but that doesn't really help us speed up anything since we need to make sure it gets installed.
Group policy. The old school way to push software requires an MSI. The programs that I was installing didn't come packaged in an MSI, it was an EXE. Yes, I know I could repackage it into an MSI, but I want to get this software installed quick and I don't want to spend the time on that.
Third party management software. Yes, this a really good option. The problem is that we're still working the bugs out of the management software right now and for an unknown reason it doesn't want to push these installers. The long term way to push software is going to be to get this fixed. But right now I'm going to postpone troubleshooting on the management software just so I can quickly get this software installed and get the end users back running.
So what did I finally go with?
PSEXEC. Psexec is your friend. It's one of the ps tools available from Microsoft (formerly Sysinternals). It's a free download and it will let you execute commands on remote systems. So with a quick (and very dirty) batch file I was a able to loop through a list of computer names and install programs that I needed to get installed.
psexec /? will give you all the options, but for my purposes here's what I used:
psexec \\machinename -user someuser -p somepassword C:\installerfilename.exe /switches
And that's it. Well, actually I used a FOR loop in a batch file to process through all the machine names, but the actual work was done with that command right there.
Here's a link for info on the FOR loop. http://ss64.com/nt/for2.html This post is starting to run so I'll save the notes about FOR loops for another post.
A login script. Great! But you have to make the script, associate with only the machines (or specific user) that you need it on, and then wait for someone to log into the machine. Or remote the machine and log in yourself, but that doesn't really help us speed up anything since we need to make sure it gets installed.
Group policy. The old school way to push software requires an MSI. The programs that I was installing didn't come packaged in an MSI, it was an EXE. Yes, I know I could repackage it into an MSI, but I want to get this software installed quick and I don't want to spend the time on that.
Third party management software. Yes, this a really good option. The problem is that we're still working the bugs out of the management software right now and for an unknown reason it doesn't want to push these installers. The long term way to push software is going to be to get this fixed. But right now I'm going to postpone troubleshooting on the management software just so I can quickly get this software installed and get the end users back running.
So what did I finally go with?
PSEXEC. Psexec is your friend. It's one of the ps tools available from Microsoft (formerly Sysinternals). It's a free download and it will let you execute commands on remote systems. So with a quick (and very dirty) batch file I was a able to loop through a list of computer names and install programs that I needed to get installed.
psexec /? will give you all the options, but for my purposes here's what I used:
psexec \\machinename -user someuser -p somepassword C:\installerfilename.exe /switches
And that's it. Well, actually I used a FOR loop in a batch file to process through all the machine names, but the actual work was done with that command right there.
Here's a link for info on the FOR loop. http://ss64.com/nt/for2.html This post is starting to run so I'll save the notes about FOR loops for another post.
Back in the Game
Looks like I took a long break. But I'm going to start back here and get back into writing again. My goal is to write more than 1 post per week. I would really like to be able to churn out one every day but I'm trying to set a more realistic goal. Hopefully, that will mean some more helpful information is going to come pouring out onto this blog. I guess the worst case is that it'll be a lot of random thoughts that come pouring out.
Subscribe to:
Posts (Atom)