allan

Hi guys, I was wondering, what is the norm in keeping mail? I have been running my own email on my server box under my desk for years, and the collection of thousands of mails has become big... Too big for many mail-reader clients to operate at full speed (Mozilla Thunderbird is slow when opening my mailbox, and my webmail application almost crashes when trying). Is it considered normal to keep many-year old mail, or am i expected to delete old mail? I like keeping old messages for the record, and going back now and sorting out and deleting would take a rediculesly long time. Is the IMAP protocol really not designed to be able to handle a few thousand mails? What do you guys do?

I have a "Command Prompt.lnk" in my users accessories folder anyway, and i guess it's created by default for each user on the system. You you could put the del lines in each users logon script. Or else maybe you could remove the links from the hidden "C:\Documents and Settings\Default User" folder. I presume this folder is the skeleton folder for all users logging on the system for the first time.

It's probably because some of the links are located in your user folder %userprofile%

Hi everyone, many thanks for all the feedback! It seems the main opinion is that GPO is the cleanest and most correct method of doing this type of automated remote installation. However, the app RogueSpear posted, "CPAU", looks really great, since it actually lets me continue using my old logon script that does the checking and installation. So I’ll try with CPAU and spare the time it takes to create MSI packages. In the future I will definitely use GPO, if I get a chance to start an environment from scratch. Thanks! :-D /Allan

Hi all, and thanks for the replys. bek and spyder2k: You're right, that sounds like a very clean solution. However, I don't think it will be the best for my situation. There are about 30 installation packages (most coded in autoit at the moment), so using GPO, it would not be possible to see how far the installation has progressed (or is it?). Also, when big packages are rolled out (like ms-office), as far as i understand, using GPO doesn’t lock the screen, and the user will be able to log on and mess up the system while its installing... And the last issue here, is as you said that packages have to be MSI. We are installing packages such as java development kit, which do not have MSI installations. twrizzo: that sounds like a solution that would work with my packages straight away! But, how is the user running the initial logon supposed to get access to write the admin login information to the registry? Thanks :-) /Allan

Hi all, I'm having some problems with logon scripts user permissions, and I would appreciate if anyone in here could give me a hint on how to fix this. The problem is simple, and I’d say there should be some simple solution! Here’s the problem: We are a large company, and we therefore install the software on our workstations automatically and unattended. These installations are started from a logon script, so when a new version of a piece of software we use is released, we simply drop in an extra line in our logon script, and the software is installed on the workstations next time a users logs on the workstation. This works great, and we have been using it for many years. However, we have now been ordered to tighten our security so users can’t install software on their local machines. This also means that the logon script that runs and should install new software won’t work, since it runs as the user who logged on. Does anyone here have any ideas to how we I could start up this logon script as a user with administrative privileges? First I tried using AutoIt to type in a password to a runas window. This wasn’t secure enough, because anyone could open a notepad window and let the autoit script type the password to the notepad window instead, or just view the script source... Then we bough some licenses for an application called ScriptLogic. It claims to be able to securely solve this problem, but it seems very overkill and messy, and has loads of features I don’t need or have already covered in my original logon script. On Linux/Unix I know a simple solution! I could chmod the sticky bit on the logon script, and in that way force it to run as root no matter who started it. Sadly, I’ve never heard of sticky bits in a Windows environment... Any hints or ideas are greatly appreciated. Thanks Allan, Denmark