End User Help

Last updated: November 15, 2023
Audience: IT Staff / Technical

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/phone/title/department.  Why hasn’t my new name/phone/title/department shown up in Outlook (i.e. the Exchange Address Book), Teams, Sharepoint Online, OneDrive for Business, the NETID domain, or our Entra ID tenant?

Most UW NetIDs can control their name via the Preferred Name capability. Changes to your public directory information (like name, phone, title, department, campus mail box) aren’t propagated in real-time.  The updates to that information take the following path:

  1. Identity.uw.edu -> UW-IT Microsoft Infrastructure  MIM server – this part of the data flow takes about ~20-30m
  2. MIM processing – this part takes ~1.5h on average
  3. NETID Active Directory replication – this part takes 15-30m
  4. Entra ID Connect -> Entra ID – this takes ~30m
  5. Office application directory – this takes 5m-5h

NOTE: The sync process from #4 to #5 is provided by an undocumented system Microsoft is solely responsible for, which occasionally has problems.

When you change your password using the Manage Your UW NetID site, you skip steps #1 & 2 in the above noted data flow.

Some applications cache directory information like names and only update them occasionally. For example, Outlook has an Offline Address Book which by default is only updated once daily. Teams sometimes needs you to sign out and sign back in to reflect updated identity information. You can also try the steps documented here: https://www.canr.msu.edu/news/clearing-the-cache-for-microsoft-teams.

If you had more than one personal UW NetID which were merged to a single personal UW NetID, this can result in a known problem to your name in Microsoft applications. Contact UW-IT for assistance in resolving this.

If your phone number is not synchronized, it may be because within your Workday profile, you have not chosen “Telephone” as the value and instead picked “Mobile”. Only the “Telephone” value is synchronized. To make sure your phone number within Workday is synchronized, go to Profile (icon in upper right) > View Profile > Actions > Personal Data > Change contact information > Primary Phone > Phone Device = Telephone.

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 changed my UW NetID password. Only my old password works on my Windows computer at home, but the new password works with Office 365. What is going on?

The process to change a UW NetID password is documented here: https://itconnect.uw.edu/tools-services-support/access-authentication/uw-netids/about-uw-netids/#passwords. That procedure results in an update to the corresponding NETID Active Directory user password. This works in all situations. The UW NetID account and password is used for access to UW Office 365 services, so any UW NetID password change immediately would affect any subsequent interactive sign in to UW Office 365.

Windows computers which are joined to Active Directory (AD) rely on network connectivity to AD for their authentication. When a Windows computer does not have network connectivity to AD, it uses cached credentials–a locally cached & hashed version of your password at the last time the user signed into the computer when network connectivity to AD was present. If your AD user password changes while a computer doesn’t have connectivity to AD, then you must use the older password because the locally cached credentials are based on the older password. If, after initial sign in to your computer which does not have connectivity to AD, you try to connect to services which rely on the AD user account for access (e.g. a Windows file server), you will be challenged to provide your existing AD user password. This is because the cached credentials are only accepted by the local computer–no other computer will accept them. This is how Active Directory joined computers have worked for 20+ years–there is nothing new about this experience.

There are four things you can do about having a Windows cached credential which is based on your old UW NetID password:

  1.  Get your device directly on the UW network & sign in. The network connection could be via an ethernet connection or wireless directly connected to the UW network–not a network provided via some other provider.
  2. Use a Windows ‘Network Sign-in” compliant VPN at Windows sign in. This requires a number of things to come together:
    1. You need a VPN solution homed on the UW network which is capable of supporting Windows sign in. Husky OnNet is NOT capable. The Managed Windows VPN is–see https://uw.service-now.com/sp?id=sc_entry&sys_id=8a9c2321db9ab348d6a77a8eaf9619d5&sysparm_category=ced37caddba2bf40d6a77a8eaf9619f3 for more on how to get it.
    2. You’ll need the VPN client setup on the Windows device
    3. At Windows sign-in, you’ll need to sign in to Windows via the VPN. An example of the user experience can be seen in the Autopilot documentation. Go to /tools-services-support/it-systems-infrastructure/msinf/aad/device/intune/autopilot/setup/, click ‘Setting up a device with Autopilot’, and scroll down to #7. The first screenshot shows the Windows sign in page and points to an icon which is used to trigger the VPN sign in experience. The 2nd screenshot shows the installed VPN clients. You sign in to the VPN which also signs you into Windows.
    4. Because your device connects to the VPN first, your Windows sign in is able to contact AD and you’ll get a fresh cached credential saved to the device.
  3. Change your UW NetID password enough times that you can cycle back to your original password
  4. Continue using your old password at Windows sign in

After changing your UW NetID password, you may get a Windows taskbar notification about updating an account. This notification is likely your Entra ID device registration (see /tools-services-support/it-systems-infrastructure/msinf/aad/authn/help/background/#deviceReg), which most versions of Office running on Windows require to allow Entra ID sign in. You will be directed to the ‘Access Work or School’ Windows setting to update your Entra ID account password. So to summarize, this notification happened because your UW NetID password was changed, which resulted in your AD user password changing, which resulted in your Entra ID user password changing, so Windows wanted to get a new Entra ID refresh token to reduce future Entra ID sign-ins to applications like Office 365.

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 yourself. You will need admin privileges on your computer to make some of these configuration changes. If you don’t have those privileges, then ask your IT support to make this change. There are two types of changes your computer may need: one affects your Windows operating system and the other affects your browser(s). There are separate sections for each of these changes.

Let’s fix up your operating system

There are multiple ways to make this configuration change-we’ve listed only a few ways but you only need to pick one. We’ve ordered the easiest ways first.

  1. Use the local security policy approach:
    1. Use “Start->Run” and type in “gpedit.msc” in the “Run” dialog box.  A “Group Policy” window will open.
    2. Click down to “Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
    3. Find the policy “Network Security: LAN Manager authentication level”.
    4. Right click on this policy and choose “Properties”.
    5. Choose “Send NTLMv2 response only/refuse LM & NTLM”.
    6. Click OK and confirm the setting change.
    7. Close the “Group Policy” window.
    8. You are done configuring Windows! Now configure your browser(s).
  2. Apply the change via a .reg file:
    1. Download this lmCompatibilityLevel5 file
    2. Unzip (or open) the zip file
    3. Double-click on the lmCompatibilityLevel5.reg file
    4. Allow the .reg file to be opened, and approve the admin warning prompt
    5. You are done configuring Windows! Now configure your browser(s).
  3. Manually use the registry:
    1. Open regedit.exe
    2. Navigate to HKLM\System\CurrentControlSet\control\LSA. Click on LSA
    3. If you don’t see LMCompatibilityLevel in the right window pane, then choose: Edit > New > REG_DWORD.
    4. Replace “New Value #1” with “LMCompatibilityLevel”.
    5. Double-click on LMCompatibilityLevel in the right window pane.
    6. Enter “5”. (hexadecimal or decimal doesn’t matter)
    7. You are done configuring Windows! Now configure your browser(s).
  4. IT Support: if the computer is domain-joined, the best way is to use group policy. The GPO setting is located at: Computer/Policies/Windows Settings/Local Policies/Security Options/Network Security: LAN Manager authentication level. Note that there could be existing group policy that sets the LMCompatibilityLevel value, so you may need to review your existing GPOs to ensure that the right value is set.

Let’s fix up your browser(s)

If you go to UW websites which ask you to authenticate in a way that doesn’t involve weblogin.washington.edu, then you may also need browser configuration changes too. An example website like that is sharepoint.washington.edu. To fix your browser configurations, find the browser(s) you use below.

Edge and Chrome:

Internet Explorer and Chrome (on Windows) rely on the Intranet zone configuration to determine what type of authentication they use with a given website. So customers need to add the URLs of UW websites that leverage Windows Integrated authentication. Examples include: https://sharepoint.washington.edu, reporting services for the enterprise data warehouse, and possibly many other URLs. You can add “Washington.edu” and “uw.edu” and likely cover all UW websites.

  1. Open the control panel, locate Internet Options and open it. If needed, you can search for “Internet Options” from the control panel.
  2. When you open Internet Options, you should see a window entitled “Internet Properties.”
  3. Select the security tab.
  4. Select “Intranet zone” and click the “Sites” button.
  5. Click on the “Advanced” button.
  6. We are finally to the place where we can make the needed changes. We recommend you add “washington.edu” and “uw.edu” here. Alternatively, you may wish to only add specific UW websites. You may have other UW DNS zones you want to add.
  7. After you’ve made your additions, click Close or OK to all the preceding Windows we opened. You are done configuring IE and Chrome!

Firefox:

  1. Open Firefox and type “about:config” in the address bar.
  2. In the ‘Filter’ field type the following “network.automatic-ntlm-auth.trusted-uris”
  3. Double click the name of the preference that we just searched for
  4. Enter the URLs of the websites you wish to have fixed with a comma delimiter between each site. For example: washington.edu,uw.edu
  5. You are done configuring Firefox!

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 /tools-services-support/it-systems-infrastructure/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 Entra ID.

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

Go to top of page