Archive for the ‘WorkStation’ Category

Summary:  Group Policy application seems straightforward enough: Group Policy Objects (GPOs) are linked to organizational units (OUs); users and computers are in OUs. All the GPOs from a user’s OU hierarchy filter down to the user.

Things get more complicated, though, when you remember that GPOs can be linked to a domain and to sites—meaning you’ll have to open a whole new console to see what’s going on. You also have to consider local security policies, which exist solely on the client computer and are applied before any domain-based policies arrive. Throw in options such as Block Policy Inheritance, No Override, and loopback processing, and it’s no wonder why there’s such a robust market for third-party GPO tools. However, with some patience and a methodology, you can do quite a bit of quality troubleshooting on your own.

Start from the Scratch

Too many administrators try to start at the top, working their way down the hierarchy of GPOs and figuring out which ones apply. That method is time-consuming, error-prone, and just plain boring. It’s a lot easier to start at the bottom—the client—and work your way up the tree. Windows XP’s Gpresult tool, for example, is a great troubleshooting tool. Run from the command line, it will tell you which groups the current user is a member of (which can affect GPO application), and give you a list of every GPO that is currently affecting the user. You’ll also see the last time that GPOs were applied to the computer. What Gpresult is displaying is called resultant set of policy (RSOP). It sorts through all the blocked inheritance, no overrides, and conflicting policies to sort out exactly which policies are being applied.

By default, Gpresult doesn’t show you which individual policies are applied or what they are set to; because GPOs successively overwrite one another as they are applied, you can still be left with a troubleshooting task to figure out which of the GPOs listed is responsible for the settings you’re seeing. Fortunately, Gpresult has a “superverbose” mode, enabled by running

Gpresult /z

This mode not only displays which GPOs have been applied, but lists every single policy that’s enabled in each GPO, allowing you to see which GPO modified which setting, and which GPO finally won out in the end. Figure 36.1 shows a portion of Gpresult’s superverbose output. In this example, the GPO being applied is Local Group Policy, and you can see exactly which registry keys each setting is modifying.

Superverbose mode also breaks down the user and computer policies, allowing you to see every setting that is affecting the current users or their machines.

Advertisements

User logon problems are sometimes hard to troubleshoot. Have you checked the Application log on the machine in question? There might be (most likely) some errors in there from source Userenv (ID’s 1053, 1054).
Turning on Userenv debug logging will also help in troubleshooting user logon problems. You can do this by adding a Registry key:

– Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
– Value: UserEnvDebugLevel
– Value Type: REG_DWORD
– Value Data: 10002 (Hex)

The log will be located in: %systemroot%\debug\usermode\userenv.log.

In the log you will exactly see what happens during logon at what time. If you see a large difference between times you’ll know what part of the logon process is causing the long delay.

An anonymous proxy server (from time to time called a trap factor) mainly attempts to anonymize trap surfing. There are discrete varieties of anonymizers. One of the more routine variations is the bare proxy. Because they are typically difficult to track, introduce proxies are principally profitable to those seeking online anonymity, from governmental dissidents to computer criminals. Some users are essentially interested in anonymity for added security, hiding their identities from potentially malicious websites appropriate for illustration, or on grounds, to further constitutional charitable rights of naturalness of philippic, instead of instance. The server receives requests from the anonymizing representative server, and thus does not profit information forth the intent purchaser’s address. Though, the requests are not anonymous to the anonymizing proxy server, and so a rank of conviction is today between the proxy server and the user. Many of them are funded through a continued advertising link to the user.

Access hold sway over: Some proxy servers implement a logon requirement. In large organizations, authorized users obligated to log on to attain access to the web. The organization can thereby track usage to individuals.

Some anonymizing surrogate servers may forward figures packets with header lines such as HTTP_VIA, HTTP_X_FORWARDED_ALSO IN BEHALF OF, or HTTP_FORWARDED, which may reveal the IP address of the client. Other anonymizing delegate servers, known as elite or ear-splitting anonymity proxies, but number the SLIGHT_ADDR header with the IP address of the agent server, making it show that the delegate server is the client. A website could quiescent be suspicious of a proxy is being toughened if the client sends packets which encompass a cookie from a antecedent to by that did not put to use the high anonymity surrogate server. Clearing cookies, and by any chance the cache, would solve this problem.

 

In most network environments, it’s a good idea to document the reasons for shutting down or restarting computers. With unplanned shutdowns, you can document the shutdown in the computer’s system log by expanding the syntax to include the following parameters:

/e /c "UnplannedReason" /d MajorCode:MinorCode

where /C “UnplannedReason” sets the detailed reason (which can be up to 127 characters in length) for the shutdown or restart, and /D MajorCode:MinorCode sets the reason code for the shutdown. Reason codes are arbitrary, with valid major codes ranging from 0 to 255 and valid minor reason codes ranging from 0 to 65,535. Consider the following example:

shutdown /r /e /m \\Mailer1 /c "System Reset" /d 5:15

In this example, you are restarting MAILER1 and documenting the reason for the unplanned restart as a “System Reset” using the reason code 5:15.

With planned shutdowns and restarts, prefix the reason codes with p: to indicate a planned shutdown, as shown here:

/e /c "PlannedReason" /d p:MajorCode:MinorCode

For instance, consider the following code:

shutdown /r /e /m \\Mailer1 /c "Planned Application Upgrade" /d p:4:2

With remote systems, you need to specify the UNC name or IP address of the system you want to shut down or restart using the /M parameter. Thus, the basic syntax for shutdown, restart, and cancel delayed shutdown become

Shutdown remote system:

shutdown /s /t ShutdownDelay /l /f /m \\System

Restart remote system:

shutdown /r /t ShutdownDelay /l /f /m \\System

Cancel delayed shutdown of remote computer:

shutdown /a /m \\System

In this example, MAILER1 is restarted after a 30-second delay:

shutdown /r /t 30 /m \\Mailer1

In this example, the system with the IP address 192.168.1.101 is restarted immediately and running applications are forced to stop running:

shutdown /r /f /m \\192.168.1.101

On a local system, you can manage shutdown and restart using the following commands:

Shutdown local system:

shutdown /s /t ShutdownDelay /l /f

Restart local system:

shutdown /r /t ShutdownDelay /l /f

Cancel delayed shutdown of local computer:

shutdown /a

where /T ShutdownDelay is used to set the optional number of seconds to wait before shutdown or restart, /L optionally logs off the current user immediately, and /F optionally forces running applications to close without warning users in advance. In this example, the local system is restarted after a 60-second delay:

shutdown /r /t 60