Is there a way to get Outlook to run in the system tray? I would like to have all my applications that run all the time like email and aggregators to run in the system tray. I do not know if this is the consensus with you guys, but they
get in the way.
Is there a way to get Outlook to run in the system tray? I would like to have all my applications that run all the time like email and aggregators to run in the system tray. I do not know if this is the consensus with you guys, but they get in the way.
Ya know... all this time I thought that menu option meant that it would hide the notification icon if it was minimized... go figure!
What about Outlook 2002?
Tanks a billion.
Thanks indeed. That has always bugged me.
This can be set in group policies via the office .adm templates as well. Along with some other neat things that are not default.
and the neat things would be?
harumscarum wrote:and the neat things would be?
Making users empty deleted items, and when I am in a really good mood forcing them all to use plain text.
manickernel wrote:Making users empty deleted items......
Man that is evil. People here would freak out if an admin did that.
It's always a balancing act. I was tongue in cheek on the plain text comment. But on the prompting to empty deleted items I have found it useful. Our users on Exchange don't realize that after deleting an item they also need to empty the deleted items folder, so it ends up being rather large. Size limitations. I also go to great lengths to educate users, but some just don't get it. Just recently we had users in our 911 department, whose workstations are severly restricted to keep them from screwing them up, going around late at night finding accessible workstations in the station to access porn sites. One of the stations they got onto controlled the VOIP telephony switch. The porn spyware/malware that ended up on that station dropped the system. So again, it is a balancing act. Sometimes I just want to shoot them though.
P.S. - They were fired for not only violating computer use policy but also leaving their posts. In addition we captured them on video doing this. Isn't it sad?
And yes, the computer on the IP switch should have been secured, there is blowback on the individual responsible for that as well.
manickernel wrote:It's always a balancing act. I was tongue in cheek on the plain text comment.
You were? We have a policy of plain text only so that's enough reason to implement that Group Policy setting. And any other settings that seem like fun!
And I can understand your deleted items issue. We also have that issue with Sent Items. Of course, that wouldn't be an issue for us if Microsoft's Outlook team would get it into their thick skulls that "If someone sends something via an IMAP account, save the Sent Item on the IMAP account, not on the Exchange server. Or at least give us the option.".
Tis my number 2 gripe with Microsoft at the moment (the #1 being "why does group policy processing time out after 60 minutes?" - waaaaaaaaay too short a period if you are installing a lot of applications on a freshly built system on a rubbish network).
I'm currently looking at all sorts of ways of using custom-built administrative templates. My biggest triumph so far being making Firefox group-policy-compliant using admin templates and a generic login script.
One of my biggest problems has been finding good documentation on developing .adm templates. Microsoft simply doesn't give good examples. Got any good sources? As for logon scripts, we have used one developed by Szabo. I don't claim this is the best solution, but has worked well for us. NOTE: a lot of the commented out lines here are simply a matter of what we use. Rather than edit I leave them in in case of a need to use them later. The most useful feature I have found is that we have only a dozen or so users that need specific unique drive mappings, and these are handled using the "userid.vbs" part of this.
'Script to Map Drives using ADSI
' * Drive Mapping Script
' * Szabo source
' * October 14, 2002
Set oNet = WScript.CreateObject( "WScript.Network" )
do while oNet.username = ""
sComputerName = oNet.computerName
sUserName = oNet.userName
sDomainName = oNet.userDomain
' * Group Information
bForce = true
bUpdateProfile = true
On Error Resume Next
' Set a variable for a script file to map user specific drives.
sLocalSets = "\\bft\netlogon\scripts\" & sUsername & ".vbs"
' Query the ADSI object to get User Information. Set up the home drive variables.
adspath = "WinNT://" & sDomainName & "/" & sUserName
set adsobj = getobject( adspath )
' sHomeDrive = adsobj.homeDirDrive
' sHomeDir = adsobj.homeDirectory
' Setup objects to map network drives.
Set oNet = WScript.CreateObject( "WScript.Network" )
Set wshShell = WScript.CreateObject("WScript.Shell" )
Set colNetDrives = oNET.EnumNetworkDrives
' Remove any drive mappings. This removes all drive mappings that might be set using
' reconnect at logon.
If colNetDrives.Count = 0 then
WScript.Echo "There are no drive mappings at this time."
For x = 0 to colNetDrives.count-1 Step 2
oNet.RemoveNetworkDrive colNetDrives.Item(x), bForce, bUpdateProfile
' Map Users Home Drive
' oNet.MapNetworkDrive sHomeDrive, sHomeDir
' Map Any Global Drives
' Map group Specific Drives
' for each prop in adsobj.groups
' select case UCASE(prop.name)
' case "NOVATEST"
' oNet.MapNetworkDrive "V:", "\\avsrvr\novatest"
' case else
' wScript.Echo "No group assignments"
' end select
' Check to see if a User Script Exists and run it.
Set fso = CreateObject("Scripting.FileSystemObject")
IF fso.FileExists(sLocalSets) then
' MsgBox "Local Settings File on the User's Home Drive"
WshShell.Run sLocalSets, 2, TRUE
I don't really have good sources for Administrative Templates. Personally, I just use the "Administrative Templates File Format" pages on MSDN to keep me right with orders of the keywords or whatever. The biggest problem with Admin Templates and probably a good reason why there isn't really any good documentation is that they are simple and because of that, there are major limitations.
The way I look at them is that they are simple ways of populating the registry. They do nothing more. It is other parts of the system which read the registry that activates whatever setting there is. That's a big leap of faith because then you start to realise you can use Admin Templates to populate certain parts of the registry that already exist and (b) you can create admin templates and couple them with scripts or applications of your own creation.
As examples, with , there are so many applications out there that store settings in registry entries. You can do what the programmers of said applications should have done and use admin templates to set certain entries for people (such as default save location, etc).
Recently, as what I was talking about above with Firefox, I have been very interested in (b) which is combing registry entries set via admin template with a login script that uses that registry entry to do things. So far, all I have done is a pretty simple proof of concept (with no error checking and a million TODOs - its a version 0.0.0.1!)
So I use this admin template:
CATEGORY "Mozilla Firefox 1.0"
POLICY "General Settings"
PART "browser.startup.homepage" EDITTEXT REQUIRED
As simple as an Admin Template gets. It just creates in the registry at HKCU\Software\Policies\Firefox a registry entry FirefoxHomepage with whatever value is set in the textbox.
I then use the following (again simple, no error checking, etc) login script:
' create shell instance
set WshShell = WScript.CreateObject("WScript.Shell")
Const ForAppending = 8
Dim FirefoxPrefsFile, HomePageKey
Set EnVar = Wshshell.environment("Process")
' Get the Preferences File
' TODO: Check if it exists (error trap and quit script)
' first read in from profiles.ini file (TODO: Rewrite the ini file parser)
set FirefoxProfileIni=new ini
FirefoxProfileIni.FileName="C:\Documents and Settings\" & EnVar("username") & "\Application Data\Mozilla\Firefox\profiles.ini"
FirefoxPrefsFile = "C:\Documents and Settings\" & EnVar("username") & "\Application Data\Mozilla\Firefox\" & FirefoxProfileIni.Value & "\prefs.js"
' create file object instances
set fso = CreateObject("Scripting.FileSystemObject")
' TODO: put in overwrite as well as append?
set file = fso.OpenTextFile(FirefoxPrefsFile,ForAppending)
' SET FROM ADMINISTRATIVE TEMPLATES
' regread in from HKCU\Software\Policies\Firefox\<settings>
' homepage setting
HomePageKey = WshShell.regread("HKCU\Software\Policies\Firefox\FirefoxHomepage")
file.Write ("user_pref(" & chr(34) & "browser.startup.homepage" & chr(34) & ", " & chr(34) & HomePageKey & chr(34) & ");")
' TODO: More settings!
' close file
(also needed is Jean Luc Antoine's excellent ini parsing class available at http://www.interclasse.com/scripts/class_ini.php).
Without the login script, the registry entry does nothing. You could put the admin template in at the very top of your Active Directory (say, as a company policy of homepage). Without the login script it does nothing. Another major plus point of doing it this way is that if you used one of the many other ways of populating the registry, you could use this login script if you didn't have an Active Directory.
The net result is that combining this login script with the admin template means that within Firefox's profile directory in the user's pref.js file (if they have one - another TODO with that script!) you get:
...(loads of settings not listed!)...
Fortunately , Firefox works with this. Its uses the latter setting as opposed to the former. Even cleaner, when you leave firefox and it saves the settings, it tidies up after you and writes to the prefs.js file just the latter homepage and removes the former (obviously, if it didn't, the pref.js file could get pretty huge pretty quickly).
This is just a simple proof-of-concept and this script and admin template is a long, long way from production quality (indeed, I plan a pretty inherent rewrite to the way it searches for the prefs.js file from being a ini read to a searching/file exist routine - so to hopefully use the same script for the non-ini-file-using Mozilla amongst many, many things). I just thought it would work as a good example though.
The other big leap of faith I had with Administrative Templates was realising that because they are just registry entries, for user-side entries you could allow normal, non-admin users to set these, especially via some sort of "User Preferences Centre" or whatever. Basically, I'm thinking of a simple application or HTML Application (HTA) which allows users to set those sort of entries within User Configuration of group policy which are "maybe some users will want this, other wont" but Group Policy doesn't really allow for that sort of user-end configuration. However, its an idea which has many pitfalls, I'm not sure I have it down right and so I wont go further into that!