Thursday, December 13, 2007

Setting Deployment Server Security

For those of you out there that manage the same Altiris Deployment Servers (DS) that you use, disregard this. For those of you out there that have someone else manage your physical servers, this may be of interest to you when it comes to using the Role and Scope security options in DS. There is a DS utility located at C:\Program Files\Altiris\eXpress\Deployment Server\TechSup\Windows\DSDBSecurity.exe. Even if a user is a full dbo of the eXpress database, they are also members of the public role. The default denies in the public role will restrict access to those users. Only System Admins (members of the local administrators group as an example) will cancel out the public deny permissions. The public deny permissions need to be removed on certain stored procedures in order for the Role and Scope security to work properly,hence the use of the DSDBSecurity.exe tool. I found this out the hard way when working on a DS6.5 server after spending part of the day setting up the role and scope security options for the jobs and computers after importing a bunch of active directory groups and assigning them the appropriate roles for my organization. I believe that there is an Altiris KB article that references the use of the tool, but I thought I would bring this out in the open to stress the use of the tool if you should decide to turn on the security options in DS. The other item that I wanted to address deals with a software piracy issue that I noticed recently. Most organizations have some type of a software repository that software is installed to the eventual end-user that requested the software to begin with. Besides the options of using NTFS permissions on the share to block unwanted users from accessing the software folders, you can implement some simple security options to minimize the possibility of software piracy (your simple end-user copying the terabyte of software from you servers onto his own computer for personal use). The use of hidden shares always comes to mind as I am a believer of the coined phrase 'They can't hurt what they can't see". One of the other easy ways to 'Lock Down' your software is to modify the MSI files that you use for software deployment by adding a runtime option that requires the MSI to run with an additional command line parameter. For example, you could use a command line option such as SOFTWAREKEY=12345678. You could generate a random hash against the MSI you are deploying and use that random number as your software key variable above. So, when deploying the software, you could call the variable like this, msiexec /i \\myserver\mysoftwareshare\mymsi.msi /qn SOFTWAREKEY=12345678. The MSI will only install if you know what the command line variable SOFWAREKEY number that is actually embedded inside the MSI. If someone tried to run the MSI without the SOFTWAREKEY command line and correct number it references, the MSI will fail. These are just some easy ways of locking down your software repository and minimizing your risk of software piracy.

Friday, December 7, 2007

Altiris Infrastructure Monitoring

I brought this topic up the other day at the Altiris Midwest User Group meeting at TAP Pharmaceuticals but wanted to mention it again as I hope you will use the free tools that Altiris provides to help with the day-to-day administration of Altiris products. Altiris provides a pretty decent server monitoring product, but it is typically used if you manage a server environment and it costs a bit of money that you may not necessarily have to spend. However, they provide the same Server Monitoring product that you can use on your Altiris Infrastructure for free. It is called Altiris Monitoring Solution for Altiris Infrastructure. You can download for free from Altiris. Once you go through the down load process, DO NOT forget to register it on their website and you will receive a license file good for 1000 nodes of the product. This can be used on your Notification Servers, Recovery Servers and Package Servers to keep track of their server performance and notify you of problems via email or SNMP traps. It comes with a report pack that includes reporting data on statistics of your event queue as well as the canned OS performance data reports including information on processor utilization, disk useage, database performance and event log data. You can monitor such things as:
  • .NET services
  • Notification Database
  • Disks
  • IIS
  • Processes
  • Notification Server event queues
  • Notification Server log files
  • Recovery Solution Server critical and non-critical errors
  • Recovery Solution Server database connections
  • Recovery Solution Server raw storage
This is a very useful tool that will allow you to be a little more proactive at resolving problems that may occur within your Altiris environment. There are other free applications that Altiris provides, but this one I feel has more than paid for some of the other solutions that I have used, just by allowing me to be proactive on some of the things that can go wrong as an Altiris Administrator. Try it out, it is free, did I mention that it's free?

Saturday, December 1, 2007

File Permissions and Attributes

I am sure that there are some of you out there that already know about this, but I find it is important enough to mention for those of you that don't know. I ran into a rather peculiar situation the other day. I needed to change the folder attributes on a remote computer and also needed to grant some Domain NTFS rights to another folder on a remote computer. After doing some digging into my old tech notes, I ran across a couple of built-in utilities that resides on just about every Windows XP computer. I decided to test my options by using Altiris Deployment Server and a couple different jobs to make the two changes mentioned above. You can use the ATTRIB command to change the files attributes of a file or folder. You can use the CACLS command to change the NTFS permissions on a file. I created a deployment server job that contained a run script command something like this --> attrib + R %systemdrive%\myfolder\myfile.txt <-- to change the file to 'Read-Only'. I then created a second job that contained a run script task something like this --> cacls %systemdrive%\myfolder /E /G %Domain Users%:W <-- to grant the domain users group 'modify' permissions to this folder. I work in an environment where the end users have their computers locked down and do not have rights to do anything on their computers. However, there are some situations where the software they are using requires them to have rights to modify a file in a directory other than their 'My Documents' folder. Hence, the reason for creating a folder on the root of the drive and granting them those rights to that folder only. Software that requires that access level is installed in that directory to allow things to work as planned. I hope this has not confused things too much, and I hope you find it as useful as I did. Especially when it comes to changing things on hundreds of systems in a very short timeframe.