Auto configure Outlook
s
I need a way to automaticly configure Win98 and WinXP Pro to change the
profile in outlook to be the same as the user who logged on.
I have 200 Computers (100 Win98 with outlook 2000,XP and 100 Win Xp Pro with
Outlook 2003), and I have 1200 users.
I need a way that it would be from the logon script.
Than'x
S
Sue Mosher [MVP-Outlook]
--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx
<s> wrote in message news:uU4Edf7i...@TK2MSFTNGP10.phx.gbl...
NA
<s> wrote in message news:uU4Edf7i...@TK2MSFTNGP10.phx.gbl...
Sounds like you have a job!!
The best way I feel is with a utility that has the ability to support all
versions of Outlook in an easy to use package.
http://goffconcepts.com/products/windows/profiler/index.html
Helpful Hints:
GOFF Concepts
Phurrough@discussions.microsoft.com Shaun Phurrough
created for a newly logged in user on a specific workstation (i.e., you
install Outlook as User A; when User B logs in for the first time, you want
the correct profile automatically setup and opened for User B). Assuming
this is correct, this functionality hasn't worked in Microsoft profiles for
awhile even though it should have (one of the reasons people have relied on
PRFs).
I discovered the problem was how Microsoft stored the user's profile
variable in the registry. Even more amusing is that they did it twice, once
within the main application itself and once again in the Custom Installation
Wizard. Please forgive me as I'm at home and will have to get the actual key
for you tomorrow. Basically, Microsoft erroneously stores an environment
variable pointing to the user's profile in a registry data type of "String"
instead of "Expandable String". Therefore, the environment variable never
gets expanded, therefore profiles have never worked right for years. If you
manually change the data type to Expandable String in the registry and in the
Custom Installation Wizard (i.e., MST), your problem will be fixed. When the
new user logs in, Microsoft Outlook will self-repair itself, creating the new
mapi profile and properly pointing it to the applicable user's folder
profile, then open the user's mailbox.
I would say I have not tried this for Outlook 2000 or 2002 (XP). I have a
feeling it will do the trick though. Otherwise, you will have to use PRFs as
indicated by Sue.
Shaun Phurrough
Systems Analyst
Sue Mosher [MVP-Outlook]
--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx
"Shaun Phurrough" <Shaun Phur...@discussions.microsoft.com> wrote in message news:86433B79-8EFB-4BA7...@microsoft.com...
Shaun Phurrough
imports, but the built in functionality of the Outlook MSI that should have
done the job. In the majority of cases, the PRF import is not necessary if
the MSI were actually doing its job to be begin with. It really depends on
what the end goal is. Basically, speaking, once you fix the issue I've been
describing, the Outlook MSI should self-heal for a new user login, create the
profile correctly for the user, and setup most of the initially desired
settings. All this should happen when the new user runs Outlook for the
first time. Unfortunately, it doesn't unless you fix the issue in the
registry mentioned in my previous post.
If you are using Domain Group Policy, you theoretically should never need to
use a PRF import (assuming you have applied the registry fix). And in fact,
our corporation doesn't use them except when there is a corrupt profile that
needs to be deleted. Using a PRF is the quickest way to handle this.
As promised, the registry key in question has to do with the PSTPath. It
may be a little confusing, especially if you aren't doing anything with PSTs
(as we are not) in Outlook 2003. But this path, if incorrect, will break the
self-healing that allows Outlook to correctly create a new user profile
without needing to import a PRF.
Registry Key: HKCU\Software\Microsoft\Office\11.0\Outlook
Registry Value Name: ForcePSTPath
Registry Value Type: REG_EXPAND_SZ
Registry Value Data: %USERPROFILE%\Local Settings\Application
Data\Microsoft\Outlook
This needs to be added to the Add/Remove Registry Entries section of the MST
(Section 12 of the Custom Installation Wizard for 2003). For this to fully
work, if you are using Group Policy, you need to alter the original ADM
Policy file for Outlook. Open the original ADM and search for the following:
KEYNAME Software\Policies\Microsoft\Office\11.0\Outlook
PART "Default location for PST files" EDITTEXT TEXT
Replace the word "TEXT" with "EXPANDABLETEXT", then save and apply the ADM
file using GPMC.
Although it may seem easier to use PRFs, it really isn't. I only had to do
this once and PRFs were pretty much a thing of the past for us. No more
problems with profiles, new users, or desired settings.
Let me know if anything here doesn't make sense.
Shaun
Sue Mosher [MVP-Outlook]
I don't know what you mean by "the Outlook MSI." An .msi file by itself contains no information that could be used for generating mail profiles.
>> > Basically, Microsoft erroneously stores an environment
>> > variable pointing to the user's profile in a registry data type of "String"
>> > instead of "Expandable String".
Is this ForcePSTPath that you're referring to? It is not necessary to add the ForcePSTPath registry value unless you want to change the path from the default, which is %USERPROFILE%\Local Settings\Application
Data\Microsoft\Outlook.
Regardless of the value of ForcePSTPath, you still need a PRF file to tell Outlook what types of accounts to use.
Good catch on ForcePSTPath missing the EXPANDABLETEXT keyword. I'll pass that along to the right folks at Microsoft, so hopefully, they can fix it for the SP2 .adm and .opa files.
Back to the original question from "S": For Outlook 2003, you create and deploy a PRF file using the methods detailed in the excellent white paper "Configuring Outlook Profiles by Using a PRF File" at http://office.microsoft.com/search/redir.aspx?assetid=HA011403051033&QueryID=pHm7c_60I&respos=3. For Outlook 2000, you also use a .prf file, but deploy it with a separate tool -- Newprof or Modprof. See http://www.slipstick.com/exs/olroam.htm for more information on that.
--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx
"Shaun Phurrough" <ShaunPh...@discussions.microsoft.com> wrote in message news:4E20EA1D-1D6E-43F1...@microsoft.com...
Shaun Phurrough
to - basically Outlook imports the PRF on first run). We have found that
selecting "Create New Profile" with the changes I mentioned actually works
better in many scenarios (assuming you aren't doing POP accounts, etc.)
I didn't reference the Outlook MSI to discuss settings. I referenced the
Outlook MSI because it is the MSI Technology that allows for self-repair,
which you can use to your advantage and have Outlook create the profile as
originally intended. Microsoft originally intended the MSI Technology to
properly setup the profile for you without having to use PRF files, etc. The
problem is that it never fully worked.
The reason you have to use the ForcePSTPath in the CIW and in Group Policy
is not because you want to change the default value, but because it is the
only way to correct the value date type in the registry (it's the only way to
make it Expandable instead of String). This particular issue is discussed in
plenty of knowledgebase articles, but many of the fixes are not necessary
when the data type is corrected in advance. By incorporating this into your
installation, the issue can be fixed and the string properly expanded. There
are many individuals with issues they don't even realize can be quickly fixed
with this setting.
I have never needed a PRF to tell what account to use for a corporate
Exchange environment. Only when there were POP and similar non Exchange
accounts. Using environment variables and the fix mentioned above works just
fine. Deployed 1000 users over 8 offices without a single issue. And anyone
can log into another workstation and have their profile automatically created
and ready to go with settings and no problems, all without a PRF.
Anyway, just an FYI. Another way to address the problem that worked better
for us in the long run.
Sue Mosher [MVP-Outlook]
> to - basically Outlook imports the PRF on first run). We have found that
> selecting "Create New Profile" with the changes I mentioned actually works
> better in many scenarios (assuming you aren't doing POP accounts, etc.)
I was not referring specifcally to Apply PRF. In fact, **all** of those CIW options (except doing nothing) create a PRF file, which is copied to the local machine for Outlook to process. And they all work (except for the bug in the Outlook 2003 CIW/CMW that won't set up a Unicode .pst file, but there's an easy workaround for that one).
> I didn't reference the Outlook MSI to discuss settings. I referenced the
> Outlook MSI because it is the MSI Technology that allows for self-repair,
> which you can use to your advantage and have Outlook create the profile as
> originally intended. Microsoft originally intended the MSI Technology to
> properly setup the profile for you without having to use PRF files, etc. The
> problem is that it never fully worked.
The role played by the MSI technology is to copy the PRF file and to set ImportPRF, FirstRun and First-Run so that Outlook will know to process the PRF file. I have never seen anything to indicate that the MSI technology was ever intended to set up mail profiles directly. It has no MAPI "smarts" and, therefore, has no capability to create mail profiles.
> The reason you have to use the ForcePSTPath in the CIW and in Group Policy
> is not because you want to change the default value, but because it is the
> only way to correct the value date type in the registry (it's the only way to
> make it Expandable instead of String). This particular issue is discussed in
> plenty of knowledgebase articles, but many of the fixes are not necessary
> when the data type is corrected in advance. By incorporating this into your
> installation, the issue can be fixed and the string properly expanded. There
> are many individuals with issues they don't even realize can be quickly fixed
> with this setting.
What KB articles are you referring to? There' s no need to use a registry value to set the same value that Outlook uses as a default (especially when Outlook's PRF processor can expand environment variables on its own).
> I have never needed a PRF to tell what account to use for a corporate
> Exchange environment.
> Deployed 1000 users over 8 offices without a single issue. And anyone
> can log into another workstation and have their profile automatically created
> and ready to go with settings and no problems, all without a PRF.
You may not have realized it, but if you set up an Exchange account with the CIW or CMW, you actually used a PRF file, whether you ever looked at it explicitly or not. CIW/CMW created it for you and copied it so that Outlook could process it. If you don't believe me, use the MST Viewer to search your MST file for PRF, then the next time you do an installation, before you run Outlook the first time, search the new system for a PRF file with the same name. For a really good time, edit it manually to change the name of the default profile that it creates. Then run Outlook for the first time.
Shaun Phurrough
regardless, and that the ImportPRF and FirstRun aspects of the MSI are used,
not self-healing, on first run. However, that still doesn't resolve my
problem.
I think the problem is that you may be interpreting my comments as trying to
explain the very base level operation and I'm not (at least not
intentionally). I'm trying to capture it from a big picture perspective, but
perhaps I'm doing a very poor job at it. Many administrators are not going
to understand the actual sequences that occur when an MSI is run (simply
because many of them don't have time). My point was that the MSI is what
handles the initial creation of the profile when a user logs in for the first
time and no profile exists yet (not meaning that it "creates" the mapi
profile, but that it facilitates the creation of the profile - unfortunately,
I was wrong about the method of facilitation - first run, not self healing -
but the fact that it does facilitate it was correct).
And the whitepaper you pointed out says nothing about the internal PRF (at
least not that I could find). So it is assumed that you are speaking of
manipulating a PRF file outside of what's internally done with the "Create
New Profile" in the CIW. My point is that I didn't have to do anything with
PRF files. They might be created without my knowledge, but I didn't
personally open one, I didn't edit one, and I didn't do anything discussed in
the whitepaper you brought up. I simply used the CIW, created an MST file
and made the registry changes I mentioned. New profiles are ALWAYS created
properly for me without issue.
We worked with senior legal consultants who have done this quite awhile as I
know you have. When I create an MST and apply it during the install, the
profile will be correctly created for the user under which I complete the
install. However, if I then log in as another user, the profile does not get
created correctly and several different errors may arise. At that point, our
supposedly only option was to use a "non-internal" PRF. I ended up NOT
having to use a "non-internal" PRF though by fixing the data value of the
before-mentioned registry key.
Finally, for some reason I'm still confusing you somehow about that registry
key. You stated:
"There' s no need to use a registry value to set the same value that Outlook
uses as a default (especially when Outlook's PRF processor can expand
environment variables on its own)."
I understand this. The value has to be set to get the value TYPE correct,
not the DATA. And Outlook's PRF processor might expand environment variables
just fine, but it still doesn't work on that "internal" PRF you mentioned, OR
else it causes a problem somewhere else, because if I don't set the value and
correct the TYPE, and I don't use a separate PRF, then the Profile does NOT
get created correctly when I log on as a different user.
That's all I'm trying to say. I feel like we are getting caught up in
details that are way beyond what I meant. I apologize for any previous
confusion.
Just for clarification, perhaps I can approach it a different way. In your
first post (in response to "S") you gave information about using PRF files to
"create or modify a mail profile". Let's assume for a moment that I don't
know anything about PRF files. What I'm saying is that changing the registry
TYPE I mentioned will lead to all my profiles getting created correctly for
any new user login without ever touching a PRF file or reading the whitepaper
you brought up (ignoring the internal PRF you mentioned because we
administrators don't know about that and I don't directly edit it). Again,
all I did was fix the data type of that registry key and my profiles began
getting created correctly as well as fixing several other issues that would
arise from time to time.
Hopefully that makes more sense, at least in respect to what I was trying to
communicate. Thanks for humoring me, Sue. Your patience is appreciated.
And thanks for the info about the FirstRun aspect about the MSI importing an
internal PRF. Didn't know that.
Best regards
Shaun
Sue Mosher [MVP-Outlook]
> handles the initial creation of the profile when a user logs in for the first
> time and no profile exists yet (not meaning that it "creates" the mapi
> profile, but that it facilitates the creation of the profile - unfortunately,
> I was wrong about the method of facilitation - first run, not self healing -
> but the fact that it does facilitate it was correct).
"Facilitates" is a good concept here. The distinction I was trying to make -- and one I feel is important for administrators to grasp (oh ye who lurk here) -- is that the MSI itself does not, in fact, create the mail profile. You can check this by looking in Control Panel | Mail before Outlook has run the first time for a user. It does, however, facilitate it by copying the PRF file and setting the registry values that allow Outlook to create the mail profile on first use. I'm glad you found that information interesting and, hopefully, useful.
> When I create an MST and apply it during the install, the
> profile will be correctly created for the user under which I complete the
> install. However, if I then log in as another user, the profile does not get
> created correctly and several different errors may arise.
That suggests several scenarios worth investigating -- the one where Outlook doesn't create a mail profile on first use and others where a profile is created but errors occur. It would be useful to know what exactly kind of errors and to get a copy of the PRF file from such scenarios.
> At that point, our
> supposedly only option was to use a "non-internal" PRF. I ended up NOT
> having to use a "non-internal" PRF though by fixing the data value of the
> before-mentioned registry key.
Can you post the settings from such a PRF file (omitting the mapping sections)?
> "There' s no need to use a registry value to set the same value that Outlook
> uses as a default (especially when Outlook's PRF processor can expand
> environment variables on its own)."
>
> I understand this. The value has to be set to get the value TYPE correct,
> not the DATA. And Outlook's PRF processor might expand environment variables
> just fine, but it still doesn't work on that "internal" PRF you mentioned, OR
> else it causes a problem somewhere else, because if I don't set the value and
> correct the TYPE, and I don't use a separate PRF, then the Profile does NOT
> get created correctly when I log on as a different user.
> What I'm saying is that changing the registry
> TYPE I mentioned will lead to all my profiles getting created correctly for
> any new user login without ever touching a PRF file . Again,
> all I did was fix the data type of that registry key and my profiles began
> getting created correctly as well as fixing several other issues that would
> arise from time to time.
I don't disagree with you on the data type. My point is that my experience with lots of different PRF deployment scenarios has never indicated a need to set that registry value at all, unless you want to change the location of the .ost and .pst files from the default that Outlook uses. As noted above, getting a copy of the PRF file that was in use when profile creation failed and when setting the registry value made it work would be useful for narrowing down where the fault might lie. If we can figure that out with a reproducible scenario, then we can give the information to Microsoft to possibly fix in a future version of the CIW or Outlook, whichever is at fault.
Shaun Phurrough
so I have to do some digging for the exact error messages and KB Articles,
etc. The main profile issue I can probably reproduce pretty quickly because
it was just a basic setup, but I have to redo an MST to remove what we have
in there to fix it.
Thanks again.