Ryan H's questions

We have a naive application that prints without having configurable options for page orientation, paper size, etc. The solution has been to create multiple queues for each set of configuration options, so that printing landscape is a different "printer" from printing portrait, etc.

We do this using EasySpooler, which we'd like to stop using if there's a good (free) alternative, since it has more power than we need, and its interface and configuration is not as easy as we'd like.

Can Windows queues have these settings forced or defaulted on a queue? If not, is there some other application or daemon that we can run to get this behavior?

I'm setting up my organization's first Terminal Server / Remote Desktop Session Host (RDSH) for Lab use. We are a college, and I am wanting to use this server (or more servers configured similarly in a farm) to power other labs on campus as well. Each of those labs will have its own shared printer.

Ideally, the thin clients would not need to have any knowledge of the printer that is in the area, as they won't be needing to print in the first place. Because the thin clients are re purposed hardware, we will be installing windows 7 on them, joining them to the domain, and using Group Policy to lock them down to minimal thin clients.

Is there some way that I can use Group Policy or Logon Scripts to have the thin client's location (Organizational Unit or something) determine which printer installed on the Server should be allowed/default to a user connecting from a given thin client?

A friend of mine in a similar situation (but unable to add the thin clients to active directory) was only able to accomplish this by having different terminal servers. In the case that we couldn't join the thin clients to the domain, is there any way that we can determine access / default printer appropriately?

I am getting a memory error in a php cron job:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 71 bytes) in /opt/matrix/core/lib/DAL/DAL.inc on line 830

The applicable parts of the crontab are:

$ sudo crontab -u www-data -l
MAILTO=root
# m h  dom mon dow   command
*/15 * * * * php /opt/matrix/core/cron/run.php /opt/matrix

I am running on Debian Squeeze, fully updated.

The obvious solution would be that the cli has a low memory limit (of 64MB). However, /etc/php5/cli/php.ini says it's unlimited.

$ cat /etc/php5/cli/php.ini | grep memory_limit
memory_limit = -1

I read somewhere that it could be different for different users, and since the process is running as www-data, i ran:

$ sudo -u www-data -s
$ php -i | grep memory_limit
memory_limit => -1 => -1
suhosin.memory_limit => 0 => 0

Even the apache/php.ini has a higher limit than the error is claiming:

$ sudo cat /etc/php5/apache2/php.ini | grep memory_limit
memory_limit = 128M

What am I missing? Where is this memory limit?

We are using Live@edu, which is essentially hosted exchange server with some additional features and limitations to work around, and I'm trying to find everybody that is forwarding or redirecting emails from their accounts.

I am trying to remove old accounts that have not been used, but we have instructions for users on redirecting emails, so we should expect that some users are indeed redirecting their emails, which will make their last login/logoff times not reflect whether they are indeed using auto forwarding or auto redirecting rules.

How could I find a list of users with forwarding or redirection rules using Exchange 2010 Powershell Cmdlets?

/EDIT: It may be sufficient for my purposes to find whether there are ANY server side rules, regardless of whether the rule forwards/redirects or does some other action.

I have set up a failover-clustered file share on a pair of Windows Server 2008 R2 Machines. This setup is working very well with all of the Windows clients that I know of, as well as with Macs running 10.6 Snow Leopard. However, the Macs on our network that are running 10.5 Leopard are not connecting as they should.

I don't expect that the failover-clustered part of the equation is causing any issues, but I thought that in the off chance that it may be causing issues, to include it here to provide a hint to whoever is willing to help.

When a machine running Leopard attempts to connect, it trys for a bit, then asks for the username and password to connect with (as expected). The username and password are entered (correctly), and almost immediately it comes back with the message A volume failed to mount. The volume "Home" could not be mounted.

When that box is dismissed, it continues to attempt to connect for a short time, then it comes up with this unexpected error:

A couple of Google searches have not come up with anything (for me) about Error code -6602.

Any ideas what this error may be, and/or how I should go about fixing it?

I am using Cluster Shared Volumes on Windows Server 2008 R2 with Hyper-V. The different volumes available have different sizes, and are physically located on different disks on the SAN. These volumes defaulted to labels such as C:\ClusterStorage\Volume1. I know that it is not possible / recommended to change where the CSV mount points are (C:\ClusterStorage), but I want to change the rest of the path to be a more useful name than "Volume1".

In the Failover Cluster Manager, under Cluster Shared Volumes, I can see these CSVs, and they are working just fine. When I go into their properties, I can see a list, which has the mount point listed, but the entries are not modifiable.

How can I change the mount point of a Cluster Shared Volume in Windows Server 2008 R2?

I have a Hyper-V Failover Cluster running using manually-configured IP addresses. On this cluster, among other machines, I have two Server 2008 R2 Enterprise Machines running failover cluster, intended for use in clustering file services. The 2 Cluster Host machines for the file server receive their IP addresses properly through DHCP. However, the cluster is NOT able to receive an IP through DHCP.

I find the following error in the cluster log:

Event ID 1240: Cluster IP address resource 'Cluster IP Address' failed to obtain a leased address.

What might be causing this problem? How can I resolve it?

I have recently set up a mail server running postfix as the MTA, and dovecot as the imap/pop3 daemon. Originally, and by default on Debian, it was using the mbox format. For reliability reasons, I decided that it would be best to use the Maildir format instead. Getting help from a friend, I successfully modified the postfix and dovecot servers to use the Maildir format with the mailboxes located in ~/Maildir.

However, mutt is still doing weird things when I try to access my mail using it. It wants to create a ~/Mail directory, and furthermore wants to look for an mbox in /var/mail/. There are a few users on the system, and while I know that I can use my .muttrc to solve this problem, how can I fix this problem for all users on my server?