IT Connect

Information technology tools and resources at the UW

End User Help

This document answers basic questions a user might have about topics related to the Microsoft Infrastructure. We welcome suggestions as to additional questions that should be added to this document.

How can I remotely access my Windows computer?

One option is Windows file sharing. All Windows computers (from Windows 3.11 for Workgroups on) are capable of sharing files with other Windows computers. This means that any networked Windows computer should be able to access a file share on another Windows computer, if the user has the proper access permissions to the file share. There are a few things you need to do to make it happen, and several provisos that you should consider. Windows operating systems since Windows 2000 have file sharing built in by default, whereas earlier Windows OS’ need an additional piece of software installed to enable this functionality. In a nutshell, one creates a file share, and then grants both share permissions and NTFS permissions to the appropriate folks.

If the computer being used to access the shared resources is not part of a domain, then you will need to specify a NETID user after you attempt to access the file share. You’ll get a login challenge, for which you’d respond:

Connect As: netid\UW NetID

Password: UWNetidPassword

This assumes that the computer with the shared resources belongs to a domain that trusts the NETID domain.

Another possible option is called Terminal Services or Remote Desktop, depending on the Windows operating system. One uses a simple client software, called a RDP client or terminal services client to remotely connect to the remote Windows computer. The connection gives you an identical graphical interface to your computer as if you were at the console.

There is one last option with Windows Terminal Services, which may be very useful to people who travel and want to use an Internet cafe to access their Windows computer. Awhile ago, Microsoft released the Terminal Service Advanced Client, which contains an ActiveX control that Internet Explorer on a Windows client can use to connect to a Terminal Server. By placing this ActiveX control on a webserver, you only need a browser, and a URL to a special webpage to be directed to your remote Windows computer. There are more details about this functionality on the Microsoft website.

Go to top of page

I recently changed my name.  Why hasn’t my new name shown up in the NETID domain, the Exchange Address Book, Sharepoint, Sharepoint Online, OneDrive for Business, Skype for Business, or our Azure AD tenant?

Right now, changes to your public “directory information” (like your name, department, campus mail box) isn’t propagated in real-time.  The updates to that information in the above list of applications happen when your account gets created, every time you change your password, and on a semi-regular basis that is about every couple hours. You can trigger an update of your name and directory information by changing your password using the Manage Your UW NetID site, but your updated name information may still lag in a given application for a variety of reasons. Some applications cache directory information like names and only update them occasionally. For cases that involve Microsoft cloud-based services, the way the infrastructure is put together means there is at least 30 minutes latency before the change will happen and in some cases the latency can be considerably worse, as much as a day or more in certain extreme situations.

Today, none of these applications supports the UW NetID Preferred Name, so changes to that value are not expected to flow to any of these applications. This will change.

There are considerably more details documented about what to expect for the name associated with an account.

Go to top of page

I used to be able to see what groups my friends and co-workers were in.  Why can’t I now?

In order to provide schools and departments across campus with access to the course-based groups, we needed to devise a way to allow use of the group without providing the ability to see who was in the group.  This information is protected by federal legislation – the Family Educational Rights and Privacy Act, or FERPA.  By locking that down, it also prevents you from casually browsing your friends’ group memberships.  You can contact us if youhave a legitimate business need to gain access to that information, such as an application that needs to integrate with our infrastructure.

Go to top of page

How do I configure my workstation so I can login interactively with my NETID user account?

To find out what users and groups have the ability to login interactively to your workstation, launch “secpol.msc”. This will bring up the Local Security Settings. On the left, open the Security Settings, open the Local Policies, open the User Rights Assignment. On the right, you should see a policy named Logon on Locally. The accompanying security setting tells you want users and groups can log into your workstation interactively. It is often the case that you will see Administrators listed. This corresponds to the local administrators group on your workstation. You can view what users and groups are members of the local administrators group by launching “compmgmt.msc”. This will bring up Computer Management. On the left, open Computer Management (local), open System Tools, open Local Users and Groups, open Groups. On the right, double-click on Administrators. You should see a list of all the members of this group. If you don’t see NETID\yourUWNetID listed, then it’s likely that you need to add it. Click on the Add button. A Select Users, Computers, or Groups window will appear. Click on the Locations button, select netid.washington.edu from the Locations window and click OK. In the text box, type your UW NetID. Click on the Check Names button. Click on the OK button. Now try to login again.

If your workstation is in a domain, it’s possible that the “logon locally” user right is controlled by your domain administrators via group policy. If this is the case, you can talk with them about this issue.

Go to top of page

My password doesn’t seem to work.  How can I fix this?

We’ve seen some rare cases where a password for the NETID domain can end up out of synchronization with your UW NetID. A good place to start troubleshooting is to change your password using the Manage Your UW NetID site.  Changing your UW NetID password will make sure the Microsoft Infrastructure has the most recent one.

Another possible solution is that you haven’t granted your UW NetID authorization to login interactively on the computer you are trying to login to. How to do that is described here.

Another possible issue is that your LM compatiblity settings are not compatible with the NETID domain. You can find out how to check and fix that here.

Go to top of page

I can login on some computers but not others. Why is this happening?

It is likely that your LM compatiblity settings are not compatible with the NETID domain. You are probably seeing an error of “unknown user name or bad password.” See What should my LmCompatibilityLevel settings be?

Go to top of page

I can login with my NETID user account, but I can’t access resources on a server even though I’ve granted that account access. What’s wrong?

It is likely that your LM compatiblity settings are not compatible with the NETID domain. You are probably seeing an error of “access denied.” See What should my LmCompatibilityLevel settings be?

Go to top of page

What should my LmCompatibilityLevel settings be?

Having an LM Compatibility level that is high helps ensure that your password is protected in a manner that will prevent others from getting it. You can fix that your self using this document.

If your workstation is in a domain, it’s likely that your LM Compatibility level is set by the domain administrators via group policy. You should talk with them about this issue. If you are the domain administrator, see more detail here.

Go to top of page

How do I limit access to a share or folder to students in a particular course?

This answer assumes that the Windows computer with file content to share is part of a domain that trusts the NETID domain. It also assumes that there is already a file share created.

There are two parts to controlling access to a file share. The first part involves the share permissions. The second part involves the NTFS permissions. Both permissions are required.

Open the Management Tool:

Launch “compmgmt.msc”. This will bring up Computer Management. If the local computer you are on is not the computer with the file share and content, then in the left pane, right click on Computer Management (local) and select Connect To Another Computer. Type the name of the computer with the file share in and click OK.

Share Permissions:

When you have Computer Management focused on the computer with the file share, in the left pane, open System Tools, open Shared Folders, open Shares. In the right pane, double-click on the share to open its properties. Select the Share Permissions tab. If the Share Permissions lists either Everyone or Authenticated Users with allow Full Control, then you don’t need change the Share Permissions and you can move onto the NTFS permissions section. If neither of those dynamic groups is granted full control, then click the Add button. Type Authenticated Users. Click OK. Select Authenticated Users in the Share Permissions tab. Click allow Full Control. Click OK to approve your Share Permissions change.

NTFS Permissions:

When you have Computer Management focused on the computer with the file share, in the left pane, open System Tools, open Shared Folders, open Shares. In the right pane, double-click on the share to open its properties. Select the Security tab. Click the Add button to bring up the Select Users, Computers, or Groups window. Within this window, click the Locations button to the launch the Locations window. Within this window, select netid.washington.edu and click OK. Back at the Select Users, Computers, or Groups window, type “uw_student” in the text box. Click Check Names. Click OK. The Security tab should now show NETID\uw_student is allowed Read permissions. If you would like to grant more permissions do that now. Click OK when you have granted the appropriate set of permissions.

More detail for Windows administrators:

This description includes two choices that may not follow best practices in order to simplify this description. Granting share permissions to a wider group than necessary is poor security practice, and it would be better to only grant netid\uw_student if that is the only group that needs access to this share. Granting access directly to the universal group netid\uw_student is generally regarded by Microsoft Curriculum to be bad form. Microsoft recommends that you first nest netid\uw_student within a domain local group, then nest that domain local group in a local group on the computer it will be used on and finally use this local group in all ACLs (share and NTFS).

Go to top of page

How do I limit access to a Web page to just faculty and staff?

We recommend that system administrators and developers read https://itconnect.uw.edu/wares/msinf/other-help/faq/services-and-netid-domain/#windowsWebAuthN. This answer assumes a less than optimal solution, as noted on that page, however, with extra work parts of this can be used with the optimal solution.

This answer assumes that the Windows computer with with the web server is part of a domain that trusts the NETID domain. It also assumes that there is already a website with content. It also assumes the use of IIS.

Open the Management tool:

On the computer with the web server, launch “%SystemRoot%\system32\inetsrv\iis.msc” to bring up the Internet Information Services (IIS) Manager. Select the website you would like to grant access to faculty and staff.

Check the Authentication protocol:

Right click on the website and select Properties. Select the Directory Security tab. Click the Authentication and Access Control Edit button to bring up the Authentication Methods window. Select Integrated Windows Authentication. See more detail on this choice below. Click OK twice.

Set IIS permissions:

Within the IIS Manager, within the website, find the file or directory that you want to grant access to staff and faculty. Select this file or directory. If this is the entire website, select the website. Right click and choose Properties. If you selected just a file, then now you should select the File tab. If you selected a directory, then now you should select the Directory tab. If you selected the website, then now you should select the Home Directory tab. Ensure that the appropriate IIS permissions are granted. Read permissions are generally what is needed, but you may wish to grant other permissions. Click OK.

Set NTFS permissions:

Within the IIS Manager, within the website, find the file or directory that you want to grant access to staff and faculty. Select this file or directory. If this is the entire website, select the website. Right click and choose Permissions. Click the Add button to bring up the Select Users, Computers, or Groups window. Within this window, click the Locations button to the launch the Locations window. Within this window, select netid.washington.edu and click OK. Back at the Select Users, Computers, or Groups window, type “uw_employee” in the text box. Click Check Names. Click OK. The Security tab should now show NETID\uw_employee is allowed Read permissions. If you would like to grant more permissions do that now. Click OK when you have granted the appropriate set of permissions.

More detail for Windows administrators:

Integrated Windows Authentication is not the best choice available. If you use basic authentication, you must require SSL encryption. With extra work you can use parts of this with Azure AD.

Instead of using uw_employee, you could certainly have used uw_faculty and uw_staff.

Go to top of page