Configuring Bash Configuration Files in Linux

Several configuration files support how your shell behaves. Some of the files are executed for every user and every shell, while others are specific to the user who creates the configuration file.

Bash Configuration Files
/etc/profile. Sets up user environment information for every user. It is executed when you first log in. This file provides values for your path, as well as setting environment variables for such things as the location of your mailbox and the size of your history files. Finally, /etc/profile gathers shell settings from configuration files in the /etc/profile.d directory.

/etc/bashrc. Executes for every user who runs the bash shell, each time a bash shell is opened. It sets the default prompt and may add one or more aliases. Values in this file can be overridden by information in each user’s ~/.bashrc file.

~/.bash_profile .Used by each user to enter information that is specific to his or her own use of the shell. It is executed only once, when the user logs in. By default it sets a few environment variables and executes the user’s .bashrc file.

~/.bashrc. Contains the information that is specific to your bash shells. It is read when you log in and also each time you open a new bash shell. This is the best location to add environment variables and aliases so that your shell picks them up.

~/.bash_logout. Executes each time you log out (exit the last bash shell). By default, it simply clears your screen.

To change the /etc/profile or /etc/bashrc files, you must be the root user. Users can change the information in the $HOME/.bash_profile, $HOME/.bashrc, and $HOME/.bash_logout files in their own home directories.

The following sections provide ideas about items to add to your shell configuration files. In most cases, you add these values to the .bashrc file in your home directory. However, if you administer a system, you may want to set some of these values as defaults for all of your Linux system’s users.

How to Use Your Pictures Folder in Windows Vista

As with documents, you store pictures in folders. Windows Vista already has a couple of built-in folders especially well suited for storing pictures. Your Pictures folder (which you’ll find in your personalized Documents folder as well as in the Favorite Links area of the Windows Explorer navigation pane) is the easiest one to get to. There’s also a folder named Public Pictures, which is the same idea as your Pictures folder. However, on a network or computer with multiple user accounts, pictures in the Public Pictures folder are available to everyone, whereas pictures in your Pictures folder are private, in the sense that only you can get to them.

There are several ways to get to your Pictures folders:

• Click the Start button and choose Pictures.

• Click the Start button, choose your personalized folder, and doubleclick the Pictures icon.

• If you’re already in a folder and see Pictures listed under the Favorite Links, click that option.

If your Pictures folder contains subfolders, you can double-click any subfolder’s icon to open it and see the pictures it contains. If you click one or more pictures, then the taskbar near the top of the window will contain a number of tasks specific to pictures. Here’s a quick overview of what each of those offers:

• Slide Show: Clicking this option makes the background go blank and then displays each picture in the folder, one at a time, in slide-show fashion on the background.

• Preview: This option enables you to choose a program to view the selected item. This is initially Paint or Windows Photo Gallery; however, you can choose a different default program as well.

• Print: See the “Printing Pictures” section that follows.

• Email: Send the selected files as an attachment on an e-mail.

• Share: Share the selected items with others on your computer or network.

• Burn: Enables you to copy all (or selected) pictures to a CD.

The same options are also available in your Public Pictures folder, as well as in any subfolder contained within Pictures or Public Pictures folders. When you’re in your Pictures folders, you can quickly switch to Public Pictures, if you like, by clicking Public -> Public Pictures under Favorite Links in the Windows Explorer navigation bar. It works the other way, too. If you’re in your Public Pictures folder, you can click Pictures in the Explorer navigation pane to go to your Pictures folder.

If your computer is connected to a network, or other people have user accounts on the same computer, you may want to share some photos with other users. Put those photos in the Public Pictures folder. Keep the private ones in your Pictures folder.
Source of Information : Wiley Alan Simpsons Windows Vista Bible Desktop Edition

Publishing a Windows Vista Calendar on the Network

Windows Calendar, a decent little program for managing your schedule. You can create appointments (both one-time and recurring), set up all-day events, schedule tasks, apply reminders to appointments and tasks, and view appointments by day, week, or month. This all works great for individuals, but a busy family needs to coordinate multiple schedules. The analog method for doing this is the paper calendar attached to the refrigerator by magnets. If you want to try something a bit more high tech, you can use Windows Calendar to publish a calendar to a network share. (Note that this is something that even the mighty Microsoft Outlook can’t do. With Outlook’s Calendar, you need to be on a Microsoft Exchange network to publish your calendar data.) You can configure the published calendar so that it gets updated automatically, which means the remote calendar always has current data. Your family members can then subscribe to the calendar to see your appointments (and optionally, your notes, reminders, and tasks).
First, start Windows Calendar using either of the following methods:• Select Start, All Programs, Windows Calendar.
• In Windows Mail, select Tools, Windows Calendar, or press Ctrl+Shift+L.
Publishing Your CalendarHere are the steps you need to follow in Windows Calendar to publish your calendar:1. In the Calendars list, click the calendar you want to publish.
2. Select Share, Publish to open the Publish Calendar dialog box.
3. Use the Calendar Name text box to edit the calendar name, if necessary.
4. Use the Location to Publish Calendar text box to type the network address of the shared folder where you want to store the published calendar. Alternatively, click Browse and then use the Browse for Files or Folders dialog box to select the network share, and then click OK.
5. If you want Windows Calendar to update your calendar whenever you make changes to it, activate the Automatically Publish Changes Made to This Calendar check box. (If you leave this option deactivated, you can still publish your changes by hand.
6. In the Calendar Details to Include section, activate the check box beside each item you want in your published calendar: Notes, Reminders, and Tasks.
7 Click Publish. Windows Calendar publishes the calendar to the network share by creating a file in the iCalendar format (.ics extension) and copying that file to the share. Windows Calendar then displays a dialog box to let you know the operation was successful.
8. To let other people know that your calendar is shared and where it can be found, click Announce. Windows Calendar creates a new email message that includes the following in the body (where address is the address of your published calendar):
You can subscribe to my calendar at address
9. Click Finish.
Subscribing to a Calendar Using the Subscribe MessageHow you subscribe to another person’s published calendar depends on whether you receive a subscription invitation via email. If you have such a message, follow these steps to subscribe to the calendar:1. Open the invitation message.
2. Click the link to the published calendar. Windows Mail asks you to confirm that you want to open the iCalendar file.
3. Click Open. If your user account doesn’t have access to the network folder, the Connect to Computer dialog box appears (where Computer is the name of the computer where the calendar was published).
4. Use the User Name and Password text boxes to type the credentials you need to access the shared folder, and then click OK. Windows Calendar opens and displays the Import dialog box.
5. If you want to merge the published calendar into your own calendar, use the Destination list to select the name of your calendar; otherwise, the published calendar appears as a separate calendar.
6. Click Import. Windows Calendar adds the published calendar.
Subscribing to a Calendar Using Windows CalendarIf you don’t have a subscription invitation message, you can still subscribe to a published calendar using Windows Calendar. Here are the steps to follow:1. In Windows Calendar, select Share, Subscribe to open the Subscribe to a Calendar dialog box.
2. Use the Calendar to Subscribe To text box to type the address of the published calendar.
3. Click Next. Calendar subscribes you to the published calendar and then displays the Calendar Subscription Settings dialog box.
4. Edit the calendar name, if necessary.
5. Use the Update Interval list to select the interval at which you want Calendar to update the subscribed calendar: Every 15 Minutes, Every Hour, Every Day, Every Week, or No Update.
6. If you want to receive any reminders in the calendar, activate the Include Reminders check box.
7. If you also want to see the published calendar’s tasks, activate the Include Tasks check box.
8. Click Finish. The published calendar appears in your Calendars list.
Working with Shared CalendarsAfter you publish one or more of your calendars and subscribe to one or more remote calendars, Windows Calendar offers a number of techniques for working with these items. Here’s a summary:
• Changing a calendar’s sharing information. When you select a published or subscribed calendar, the Details pane displays a Sharing Information section, and you use the controls in that section to configure the calendar’s sharing options.
• Publishing calendar changes. If your published calendar isn’t configured to automatically publish changes, you can republish by hand by selecting the calendar and then selecting Share, Sync.
• Updating a subscribed calendar. If you didn’t configure an update interval for a subscribed calendar, or if you want to see the latest data in that calendar before the next update is scheduled, select the calendar and then select Share, Sync.
• Synchronizing all shared calendars. If you have multiple shared calendars (published and subscribed), you can synchronize them all at one time by selecting Share, Sync All.
• Sending a published calendar announcement. If you didn’t send an announcement about your published calendar, or if you want to send the announcement to different people, select the calendar and then select Share, Send Publish E-Mail.
• Stopping a published calendar. If you no longer want other people to subscribe to your calendar, select it and then select Stop Publishing. When Calendar asks you to confirm, click Unpublish. (Note, however, that if you want your calendar file to remain on the network share, you first need to deactivate the Delete Calendar on Server check box.)
• Stopping a subscribed calendar. If you no longer want to subscribe to a remote calendar, select it and then press Delete. When Calendar asks you to confirm, click Yes.Source of Information : Que Networking with Microsoft Windows Vista

Tips for Terminal Services RemoteApp

One of the biggest improvements and enhancements of Terminal Services in Windows Server 2008 is in the area of experience features, Terminal Services RemoteApp, which enables users to access standard Windows-based programs from anywhere by running them on a terminal server instead of directly on their client computers. In previous versions of Terminal Services, you could remote only the entire desktop to users’ computers. So when a user wanted to run a program remotely on the terminal server, she typically double-clicked on a saved .rdp file that the administrator previously distributed to her. This connected her to the terminal server, and after logging in (or being automatically logged in using saved credentials), a remote desktop would appear on her computer with a pin at the top pinning the remote desktop to her local (physical) desktop. The user could then run applications remotely on the terminal server from within her remote desktop, or she could minimize the remote desktop if she wanted to run applications on her local computer using her physical desktop.
TS RemoteApp solves this problem (and makes the lives of harried help desk staff easier) by allowing users to run Terminal Services applications directly on their physical desktop. So instead of having to switch between two desktops, the user sees the RemoteApp program (the program that is running remotely on the terminal server instead of on her local computer) sitting right there on her desktop, looking just like any other locally running program.
Using TS RemoteAppFirst, we’ll open Server Manager and select the TS RemoteApp Manager node under Terminal Services. (We could also open TS RemoteApp Manager from Administrative Tools.)
TS RemoteApp Manager lets us specify which programs our Terminal Services users will be able to run remotely on their normal desktops. Right now, we have no programs on the Allow list, so let’s click Add RemoteApp in the Action pane at the right. This launches the RemoteApp Wizard. Clicking Next presents us with a page that allows us to choose which installed programs we want to add to the RemoteApp programs list. We’ll choose Paint.
Clicking Next and then Finish causes Paint to be added to the RemoteApp programs list with default settings.
If we select Paint in the center (Details) pane and click Properties in the Action pane, we see the default settings for running this RemoteApp program:
What these default settings indicate are that users will not be allowed to add their own command-line arguments when running Paint. (This is usually a good idea, though as far as I know, Paint doesn’t have any command-line switches.) The settings also indicate that the RemoteApp program will automatically be made available to users through Terminal Services Web Access (though we actually haven’t added that role service yet to our terminal server). In addition, we could change the name of the RemoteApp program to something other than “Paint” if we want users to know that they’re running the RemoteApp version of the program and not the version installed on their local computer.
Once we’ve added Paint to the RemoteApp programs list, how do we actually enable the user to run the RemoteApp program? To do this, we need to deploy a package containing the RemoteApp information for Paint to our users. We can package our RemoteApp program in two ways: as a Windows Installer file or as a Remote Desktop Protocol file. Let’s use the Windows Installer file approach because as administrators we’re used to deploying Windows Installer packages to client computers using Group Policy.
Start by selecting Paint in our RemoteApp programs list, and then click Create Windows Installer Package in the Action pane. This starts the RemoteApp Wizard again, but after you click Next the wizard displays the following page instead of the previous one:
By default, we see that our Windows Installer package (which will actually be created with the extension .rap.msi, with RAP presumably standing for RemoteApp Package) will be saved at C:\Program Files\Packaged Programs. We could elect to save it there, or we could save it on a network share instead, which is likely the better choice. This page of the wizard also lets us customize the terminal server settings (server name, port, and authentication settings), specify that the package is digitally signed to prevent tampering, or specify Terminal Services Gateway settings if we’re using this feature.
Accepting the default and clicking Next brings us to this wizard page:
Note that by default the RemoteApp program is going to be added to the user’s Start menu in a folder named RemoteApps. (We’ll see that in a moment.) By selecting the check box at the bottom of this page, we can also cause the RemoteApp program to launch whenever the user double-clicks on a file extension like .bmp that is associated with the program. Click through now to finish the wizard.
Now we just need to deploy the .rap.msi package by using Group Policy. After the package has been installed on these computers, now when the user clicks Start and then Programs, the RemoteApp program can be seen on the Start menu:
Now we select Paint under RemoteApp, and the following appears:
We’re also prompted for our user credentials because it’s the first time we’re running this RemoteApp program from our terminal server.
Once the RemoteApp is running, if we also start a copy of Paint locally from Accessories, then we’ve we had two copies of Paint running.
One more thing-what if we did have the Desktop Experience feature installed on our terminal server? In that case, both copies of Paint on our desktop would look identical. How could we tell then whether or not we’re using TS RemoteApp to run one of these copies? Try Task Manager-opening Task Manager displays the two copies of Paint that are running:
Notice that the remote version of Paint is clearly marked this way. Now right-click on the remote Paint application and select Go To Process. The Process tab now opens, and we see that mstsc.exe (in other words, RDC 6.0) is the actual process hosting our remote copy of Paint:
Benefits of TS RemoteAppNow that we’ve examined the new RemoteApp feature of Terminal Services in Windows Server 2008, what do you think the benefits are? Several come to my mind:
• No more user confusion over why they need to have two desktops instead of one. And that’s not to forget the gratitude your help desk staff will have for you.
• A great new method for easily deploying new applications to users-that is, using small (generally less than 100-KB) .rap.msi files deployed using Group Policy software distribution.
• Less work for you as administrator because you no longer have to configure entire remote desktops for users but only RemoteApp programs, and this you can easily do using a wizard.
• No more getting caught up in the argument of whether Terminal Services is for rich clients or thin clients-RDP 6.0 together with RemoteApp makes every client rich.
What are some best practices for using TS RemoteApp? Well first, if you have some programs that are intended to work together-that is, they share data by embedding or linking using DDE-it’s a good idea to run these RemoteApp programs from the same terminal server instead of dividing the programs up onto different terminal servers. That way, the experience for users will be enhanced, and they will see better integration between different programs when they run them. And second, you should put different programs on different terminal servers if you have application compatibility issues between several programs or if you have a single heavy-use application that could result in users filling the capacity of one of your terminal servers. (Use the x64 architecture instead of x86, however, if you want much greater capacity for your terminal servers.)

Windows Server 2008 DHCP

Dynamic Host Configuration Protocol (DHCP) is a set of rules used by network communications devices to request and obtain an IPv4 or IPv6 address lease assignment from the available pool of administrator-specified addresses. DHCP alleviates the need for network administrators to actually make such assignments by hand, freeing them up to handle other tasks.
A DHCP server ensures that uniquely-generated, dynamically allocated IP assignments are made to connecting clients, along with whatever preferential server settings may apply to the client connection. However, it can also ensure that the same IP is given only to a specific machine every single time it connects. DHCP is successor to an older Boot Protocol (BOOTP), which achieved a very similar goal.
DHCP automates not only the assignment of IP addresses but also subnet masks, default gateways, and other lease-related parameters. On boot-up, a connecting client will issue a request to the network for its personal address assignment to the DHCP application service. In turn, the service applies a set of rules that govern the assignment and return the requested information back to the client.
DHCP provides three modes for allocating addresses:
• Dynamic: Clients are provided an address assignment lease that expires after some specified duration of time. Reconnecting client computers may or may not receive the same IP address, and no real concern is given to consistency.
• Automatic: Also known as DHCP Reservation, an automatic assignment is one where a given address is permanently assigned to a particular client. The DHCP server selects from a range specified by the administrator.
• Manual: Client-based address selection and DHCP protocol message response inform the server of the new address allocation. The DHCP server performs the allocation based on a table with interface hardware or MAC addresses, where administrators manually specify IP and MAC pairs for connecting clients.
Network administrators not only reduce the amount of repetitive and potentially unnecessary effort associated with manual address assignments, but also eliminate the potential for configuration mistakes when configuring multiple clients.
Windows Server 2008 enhancements to DHCP include IPv6 support (DHCPv6) and Network Access Protection (NAP) enforcement, which requires a connecting DHCP client to prove its system health status before receiving an address assignment.

How to Configure Windows Server 2008 Firewall

Two different utilities are used to configure the Windows Firewall on a server running Windows Server 2008: the Windows Firewall Settings dialog box and the Windows Firewall with Advanced Security snap-in.
The Windows Firewall Settings dialog box provides access to only a somewhat basic collection of settings. For example, you can quickly turn the firewall on or off and set basic exceptions (in relation to software that allowed through the firewall). You can also select the network connections (if the server has multiple network adapters) that are protected by the firewall and specify the network connections you want protected by the firewall.
To open the Windows Firewall Settings dialog box, open the Control Panel (Start, Control Panel). Then select the Allow a Program Through the Windows Firewall link under the Security group. This opens the Windows Firewall Settings dialog box with the Exceptions tab selected.
The Windows Firewall Settings dialog box has three tabs:• General— This tab enables you to turn the Firewall on or off (via the On and Off option buttons, respectively) and also provides a Block All Incoming Connections check box, which blocks all incoming connections (designed for connections to unsecured, public networks) and also ignores all exceptions that you have specified.
• Exceptions— This tab enables you to select from a list of default program exceptions. You can select a program from the list to add that exception. You can also add a program to the exceptions list by using the Add Program button. You can also open a port in the firewall with the Add Port button.
• Advanced— This tab enables you to select (or deselect) the network connection or connections (on the computer) that are protected by the firewall.
If you edited the exceptions for the Window Firewall and would like to return to your default settings, click Restore Defaults on the Advanced tab of the Windows Firewall Settings dialog box.
The Windows Firewall Settings dialog box provides you with a quick way to open a port or allow a particular application through the firewall. However, it is more of an end-user tool and is not designed for access to more advanced firewall settings.
In terms of working with the more advanced settings (basically meaning rules, which are really full-blown policies when taken together), you need use the Windows Firewall with Advanced Security, which can be configured for the Windows Firewall snap-in. This snap-in enables you to manage inbound and outbound rules that are preconfigured for the firewall. You can also create new inbound and outbound rules with the snap-in. You also have the option of creating connection security rules that enable you to restrict connections to a server, based on authentication requirements that include domain membership or other criteria such as health policies.
To open the Windows Firewall with Advanced Security, select Start, Administrative Tools, and then Windows Firewall with Advanced Security. The MMC opens, containing the snap-in.
In the Details pane (when the Windows Firewall with Advanced Security on Local Computer node is selected) an Overview box provides a list of three firewall profiles: Domain, Public, and Private. These profiles relate to network connection types (and so have different settings based on the connection risks related to those network connection types) and are defined as follows:
• Domain— Computers running Windows Server 2008 and Windows Vista can recognize physical networks that are part of a domain. The domain connection profile on the firewall requires that computers be authenticated (in the domain) to access the domain controller. The domain network connection (or profile, if you prefer) is special in that it refers to a logical network rather than a physical network such as the public and private profiles that defined in a moment.
• Public— The public profile is used by the firewall to protect the computer when it is on a public network. A public network connection would be any connection that you make in a public place (via Wi-Fi). Because a server running Windows Server 2008 is typically not a device that you take on the road with you, the public connection refers to any connection that is not on your local and secure network, meaning the network that sits behind your perimeter firewall.
• Private— The private profile is used by the firewall to protect the computer when it uses a private connection, meaning a network protected by a hardware firewall.
As the network administrator (or at least the server administrator), you determine whether or not a new connection is public or private, and Windows Server 2008 asks you to identify the network as such (public or private) when you use the Connect to a Network task in the Network and Sharing Center. When the type of network to which the computer is connected is identified, Windows can optimize some of its configuration, especially its firewall configuration, for the specified network location type.
Because you have three potential profiles to work with (domain, public, and private) and each profile can have different settings in terms of firewall rules, you are provided a great deal of flexibility in terms of configuring the Windows Firewall. For example, any connections to a public network use the public network profile, which can be configured with a more robust and protective set of rules, whereas the private network profile could contain less restrictive rules related to such things as file and print sharing. Because the Windows Firewall on domain servers and on Windows network clients can ultimately be configured based on Group Policy, the overall flexibility of the firewall settings makes it easier for you to protect individual hosts on the network by using group policies that dictate specific firewall rules.
Before you consider how to configure the Windows Firewall and work with inbound or outbound rules, you need to understand how the connection type profiles are applied when the firewall examines network traffic. For computers that are part of a domain (both servers and clients), the domain profile is applied first (which really protects the domain controllers in the domain because authentication is required).
It then comes down to whether you apply the public or private profile. If the computer’s network interface (or interfaces) is authenticated to a domain controller, the private profile is applied because the connection to the domain controller itself dictates that a trusted private network is in place. If the computer’s interface is not authenticated to a domain controller, the public profile is applied.
Each of these network connection profiles can be configured separately. Let’s look at the Windows Firewall Properties dialog box and then at firewall rules.

Running Licensing Diagnosis on a Terminal Server

The Licensing Diagnosis tool is now integrated into the Terminal Services Configuration MMC snap-in (TSConfig.msc). This tool on the terminal server, in conjunction with the TS Licensing Manager’s Review Configuration option on the License Server, can be useful in finding problems arising because of a misconfigured TS Licensing setup. The Diagnostic tool does not report all possible problems in all possible scenarios during diagnosis. However, it collates the entire TS Licensing information of Terminal Services and the License Servers at a single place and identifies common licensing configuration errors.
Upon launch of the Licensing Diagnosis tool, it first makes up a list of License Servers that the terminal server can discover via auto-discovery and also those that can be discovered via manual specification by using either the Use The Specified License Servers option in TSConfig.msc (registry-by-pass) or the Use The Specified Terminal Services License Servers Group Policy. It then contacts each License Server in turn to gather its configuration details, such as the activation state, License Key Pack information, relevant Group Policies, and so on. For this to work properly, we need to make sure that the Licensing Diagnosis tool has been launched with credentials that have administrator privileges on the License Servers. If needed, use the Provide Credentials option to specify appropriate credentials for each License Server individually at run time. Then the terminal server’s licensing settings-such as the licensing mode, Group Policies, and so on- are analyzed and compared, together with the License Servers information, to summarize common TS Licensing problems. A summary of diagnostic messages, with the possible resolution steps, is provided by this tool at the end of diagnosis.
We can understand how the tool can be used by considering some sample scenarios.
The terminal server has just been set up, and the licensing mode of the server has remained in Not Yet Configured mode. No other Licensing settings have been done on the TS, and a License Server has not been set up. Within the grace period of 120 days, TS has allowed connection to clients.
Past the grace period, the administrator observes that the clients are no longer able to connect. The administrator launches the diagnostic tool and finds that two diagnostic messages are reported. One message is that the TS mode needs to be configured to either Per-User or Per-Device mode, and the other is that no License Servers have been discovered on the terminal server. The administrator now sets the TS licensing mode to Per-Device mode using TSConfig.msc. (If the TS licensing mode is set up using the Set The Terminal Services Licensing Mode Group Policy, the Licensing tab in TSConfig.msc is disabled.) A License Server is also set up by the administrator in the domain. When rerunning the tool, it now reports that the License Server needs to be activated and License Key Packs of the required TS mode need to be installed on the License Server. And so on.
Case 2: Advanced Diagnosis CasesThe Terminal Services License Server Security Group Policy has been enforced on the domain. The administrator has not added the TS computer name into the Terminal Server Computers local group on the License Server. When the Licensing Diagnosis tool is launched, it displays a diagnostic message indicating that licenses cannot be issued to the given terminal server because of the Group Policy setting. This can be corrected by using the Review Configuration option in TS Licensing Manager to create the TSC group, and TS can be added to the group using the Local Users And Groups MMC snap-in.If the License Server computer name is not a member of the Terminal Server License Servers local group in the Active Directory Domain Controller of the TS’s domain, peruser licensing and per-user license reporting will not work. In such case, when the Licensing Diagnosis tool is opened on TS, the Per-User Reporting And Tracking field in the License Server Configuration Details panel indicates that per-user tracking is not available. This can be corrected by using the Review Configuration option in TS Licensing Manager to add the License Server computer name into the Terminal Server License Servers group.
Case 3: License Server Discovery Diagnosis on the Terminal ServerDuring License Server setup, the administrator selected to install the License Server in the Forest Discovery Scope. But as the administrator ran the installation without the required Active Directory privileges, the License Server did not get published in the Active Directory licensing object. When the Licensing Diagnosis tool is launched on the TS, it is unable to discover the License Server. For diagnosing discovery problems, the administrator can initially specify the License Server by manually configuring it in the Use The Specified License Servers option in TSConfig.msc so that the License Server shows up in the diagnostic tool. When rerunning the Licensing Diagnosis tool, the administrator notices that the License Server’s discovery scope is visible in the License Server Configuration Details section. The discovery scope shows up as Domain Scope, instead of Forest Scope. This can be corrected by using the Review Configuration option in TS Licensing Manager and exercising the Change Scope option to set the License Server discovery scope to Forest Scope.
Case 4: Licensing Mode Mismatch DiagnosisThe terminal server is configured in Per-Device licensing mode, but the administrator has installed Per-User licenses on the License Server. On launching the Licensing Diagnosis tool, a diagnostic message shows that the appropriate type of licenses are not installed on the License Server, indicating a potential mode mismatch problem.