If you don't know the server names check with your email provider. Enter your SMTP server name. Enter your user name. Most ISP require your email address, other use just the alias, Check with your provider if unsure. Enter your password. Add a check to Remember password, if desired. In most cases, the SPA box will be unchecked. If your mail provider uses SPA their documentation will tell you to check that box. If any entry contains a red X, read the error tab to see what is causing it to fail.
One common cause is SMTP authentication — we'll discuss that next. General : Change the account name to a friendly name by default it uses the incoming mail server name and enter a Reply to address field and organization company name if desired.
You only need to fill in the Reply to field if you want replies to go to a different account. For example, your ISP requires you to use the address they assigned you to send email but you want replies sent to a different mailbox Outgoing server : Use this tab to set your authentication methods. Check with your mail provider to find out what authentication method they use. Connection : This tells Outlook how you connect to the mail server.
Most people will leave this tab on the defaults, but if you use a dialup account or VPN to connect to your server, select it here. This tab is also used to leave the mail on your server or change your time out's. Keep in mind that leaving mail on your server counts against your available server space and can cause your mailbox to stop accepting mail.
Select Account is disabled to disable this user account. The user account will appear on clicking Users node under Local Users and Groups on the right panel of the window. Right-click the user and then select Properties from the menu that appears, as shown in Figure Click Member of tab. The group s with which the user is currently associated appears. Click Add. The Select Groups dialog box appears, as shown in Figure 7. Also if you want to choose different locations from the network or choose check the users available, then click Locations or Check Names buttons.
The selected group will be associated with the user and will appear in the Properties window of the user, as shown in Figure The process of creating a domain user account is more or less similar to the process of creating a local user account. The only difference is a few different options in the same type of screens and a few steps more in between. Also when you create a user in domain then a domain is associated with the user by default. However, you can change the domain if you want.
Besides all this, although, a domain user account can be created in the Users container, it is always better to create it in the desired Organization Unit OU. The New Object —User dialog box appears, as shown in Figure Provide the First name , Last name , and Full name in their respective fields.
Provide a unique logon name in User logon name field and then select a domain from the dropdown next to User logon name field if you want to change the domain name. The domain and the user name that you have provided will appear in the User logon name pre-Windows fields to ensure that user is allowed to log on to domain computers that are using earlier versions of Windows such as Windows NT.
The second screen of New Object —User dialog box appears similar to Figure 4. Provide the User name and the Password in their respective fields. Verify the user details that you had provided and click Finish on the third screen of New Object —User dialog box. Follow the steps mentioned in Creating a Local User Account section to associate a user to a group. Just like user accounts, the groups on a Windows Server computer are also of two types, the built in local groups and built in domain groups.
INI files, even if these. INI files are stored in common locations. This architecture is set up automatically when a server is placed into "install mode" for application installation. Refer to Chapter 5 for more information on install mode. When an application is installed while the server is set to "install mode," any. INI configuration files usually written to common folders are instead diverted to the user profile location.
For example, if an application installation procedure tries to create a file called application. Then, whenever the application looks for its application. INI file in the user profile, not the one in the common Windows folder.
This allows each user to maintain his own unique settings for applications, even if the applications don't properly use the Windows registry. In order to further understand user profiles, let's examine a sample.
Figure 6. In the real world, all user profiles are different, but this table lists the basics. It's important to note that every user who logs on to your Terminal Server has some form of user profile, even if that user only runs a single application and not a Windows desktop. This is due to the fact that running an application in an RDP session does not prevent Windows from running a server desktop in the background.
Terminal Server hides this desktop from the user so that the user can use his own local desktop. Now that we've reviewed the basics of Windows user profiles, let's take a look at the four different ways that profiles can be used in Terminal Server environments:.
Every Terminal Server user profile must be one of these four types. Each type is useful for different situations, and you can mix and match different types on the same server as needed. A "local profile" is a user profile stored locally on one computer. Local profiles contain the files, folders, and registry settings for each user as previously discussed.
However, local profiles are only applied to the user environment when the user logs on to the computer where the local profile is stored. Because local profiles only apply when the user logs on to the particular computer where the profile is stored, they work best when users are allowed to save their settings and configurations in single-server environments.
As outlined in Figure 6. If the user's profile is found, it is loaded into memory and its settings are applied. If the system cannot find an existing local profile for the user, a new local profile is created by making a copy of a generic profile template. This creates a local profile for the user, and any changes made to the configurations or preferences are stored in the user's new local profile.
When the user logs off, the system retains the user's local profile so that the next time the user logs on to that computer his own customized environment is loaded complete with pink backgrounds and dinosaur cursors. Local profiles work well when users only log on to one server. The main disadvantage of local profiles is that they are always "local" to the computer where they were created.
If a user has a local profile on one computer and logs on to another computer, a different local profile will be used or created. There is no way for the second computer to access the profile that the user has created on the first computer. Obviously, local profiles can cause problems in an environment with multiple Terminal Servers since each server will contain a different local profile for each user.
In an environment with five Terminal Servers, each user would have five different local user profiles. Users would get a different profile depending on which server they logged on to. Confusion would be compounded when users connected to load-balanced applications where they are automatically connected to the least busy server. One day, a user might connect to Server A.
The next day, he might get Server B. From the user's standpoint, each day could bring a different profile with a different Windows background or application settings. In light of this scenario, it would be helpful if there were a way to store user profiles in a centralized location, allowing the user to get his own profile no matter what Terminal Server he logged on to. Roaming profiles accomplish just that. A roaming profile is a user profile stored on a network share instead of on a local computer.
When the user logs on to a computer, the computer checks to see if that user is configured to use a roaming profile. If so, the computer copies the contents of the user's profile from the network share to the local computer, and the profile is loaded into its memory.
In this way, each user gets her own environment no matter where she logs on. Any changes that the user makes throughout the session are saved in the profile. When the user logs off, the profile is copied back to the original network share. That way, the next time the user logs on, the environment is exactly as she left it, even if she logs on to a different computer. For a user to have a roaming profile, you simply specify the network path where the profile will be stored.
When configuring a user's domain account, you will see two profile fields listed in the user's properties. These two fields are empty by default, indicating that the user is configured for a local profile. To configure a roaming profile, you must understand the differences between these fields and how they relate to each other. Let's consider what happens when a domain user logs onto a Terminal Server.
You can visualize this process with Figure 6. When a domain user logs on to a Terminal Server, the server contacts a domain controller and receives the user's profile paths. It then attempts to load that user's roaming profile from the network path specified in the "Terminal Services Profile" text field property of the user's account. If that field is blank, the server will attempt to load the roaming profile from the path specified in the "Profile Path" text field.
If that field is also blank, the server knows that no roaming profile has been specified, and so it creates or uses a local profile. If a user logs onto a non-Terminal Server, the system will immediately look for the roaming profile in the "Profile Path" location, bypassing the "Terminal Services Profile" text field.
This allows you to specify different profiles for users depending on whether they log on to a Terminal Server or a regular computer. This is useful because profiles on Terminal Servers tend to be different from profiles on regular workstations. When a user with a roaming profile logs off of a computer, the roaming profile is copied from the computer back up to the roaming profile master location. As a result, the user will access the most up-to-date profile the next time he logs on, including any changes made during his last session.
Roaming profiles contain the same components, files, and folders as local profiles. In fact, if you were to compare the two types of profiles, you would find them to be identical. The only difference is that a profile stored in the network location specified in the user's domain account properties is called a "roaming profile.
Roaming profiles are great for Terminal Server environments, although there are a few things that you need to be careful with.
The first is that as users use their profiles, the collective size of all the files that make up the profile will start to grow. Left unchecked, user profiles can potentially grow to several or even hundreds of megabytes. This can severely slow down the logon and logoff process since all those files would need to be copied across the network.
This is so important, in fact, that a whole section of this chapter is dedicated to limiting the size of your roaming profiles. Another potential problem with roaming profiles occurs when you have multiple groups of Terminal Servers separated by WAN links. On which side of the WAN do you store the profiles for users who need to use servers on both sides? If you need strict control over your users, you can implement mandatory profiles.
Mandatory profiles are a form of roaming profile. They both operate in the same way, except that with mandatory profiles the user's settings are not saved when they log off. Any configurations or settings that the user changes are not retained. Mandatory profiles allow you to create standard profiles distributed to multiple users.
They prevent users from "breaking" anything, since their changes do not get copied back up to the master profile location when they log off. The next time they log on, their mandatory profile is downloaded again, exactly the same as it was the first time. The last profile type is called a "flex" or "hybrid" profile. These terms are usually interchangeable. A flex profile is not really a profile type as defined by Microsoft.
Instead, it is process that combines the security and control advantages of mandatory profiles with some scripting to achieve the flexibility of roaming profiles. Flex profiles have the advantages of roaming and mandatory profiles without the weaknesses. Flex profiles allow you to control the user environment while still letting the users have some leeway in what they can and cannot change.
The best part about flex profiles is that you can define which parts and settings of the profile are retained the next time the user logs on and which are discarded. With the flex profile, you configure a mandatory profile for your user's Terminal Server session.
This mandatory profile is loaded the first time a user logs on to your Terminal Server. The user works in her environment and modifies her settings as usual most likely Office settings. Q: Should I stay logged in with the Administrator account or the plain user account? A: You should log out when you are not doing work on the server directly, however, if you have a program that requires you to be logged in for it to work a good example is the bandwidth monitoring program, DU Meter then you should stay logged in with the ordinary user account.
About me. Main page.
0コメント