Skip to content

Archives: Service News

News content type for use by UW-IT Services on IT Connect

Change in printer support

As many of you may be aware UW-IT retired the Computer Maintenance Group (CMG) back in June, 2014. This group provided printer support for the Seattle campus including MWS customers until June, 2014. Since the retirement of the Computer Maintenance Group we have continued helping intermittently with printer issues for some of our customers. As of today, the Managed Workstation Service will no longer provide printer support. By stopping this support we are keeping with UW-IT’s mission to provide technology services in line with the University’s priorities.

Ceasing this support is in line with UW-IT’s mission to support the University’s environmental and sustainability initiatives, in this case, UW Managed Print Services.

If you need assistance installing, uninstalling or troubleshooting a printer there are written instructions available on our IT Connect site: https://it.uw.edu/wares/nebula/other-it-services-and-help/printing/.

Below are some printer options in the event you have a printer that needs to be serviced:

UW Managed Print Services

UW Managed Print Services is available for a monthly fee, and includes equipment (multi-functional devices that can copy, print, scan and fax), supplies (except paper) and service from Ricoh. See http://f2.washington.edu/mps/.

Local Computer and Printer Repair Shops

 

  • Departments can work directly with the following local vendors with which UW-IT has historically had good working relationships:
  • Xerox Printers: Integrity Business Systems; 888-840-0844
  • HP Printer repair: CPR Computer and Printer Repair;cprnw.com/hewlettpackard.htm; 1-800-955-4075
  • Computer Repair: Up Time Technology (on N 45th)) uptimetech.com; 206-547-1817.

 

Please send an e-mail to help@uw.edu if you have any other questions.

On-going Problems H: and I: Drives

Last month we experienced a significant incident where the server infrastructure behind H:\ and I:\groups was unable to accept new connections.  We applied a workaround, moving all user home directories and group directories to new server infrastructure, which also has much newer software, before we had completed testing and validation.  Since then, we’ve had a series of smaller, intermittent incidents, the continuing nature of which makes them all the more frustrating.  Work to identify the cause(s) of these issues and resolve them continues.  We are also looking at alternatives, including changing the underlying technologies in use.  As we’ve seen, however, such changes can have undesirable impacts of their own.

Managed Work Station FY17 Rates

FY17 rates for Managed Workstation services are now available.

As of 7/1/2016 the new FY17 rates for Managed Workstation service have been approved by Management Accounting & Analysis (MAA). MAA provides final approval of rates for all cost-recovery centers at the UW.

The rates are:

*             Managed Workstation rate: $34.50/desktop/month

*             Managed Workstation file storage: $.15/GB/month

*             Windows File Storage: $.37/GB/month

*             Consulting Services: $98.50 Hour

If you haven’t provided an eligibility group that you manage for your department, you really need to do that. Contacts for Managed Workstation departments should contact us to transition from the temporary eligibility groups we created on your behalf last summer. To see whether you still have a temporary eligibility group visit https://support.nebula.washington.edu/myIT/myNebulaDepartments.aspx. If the group listed starts with u_nebula_temp then you need to take action. This allows you to tell us who your active users are.

If you have any questions or concerns, please contact me.

Managed Workstation service will update MyIT pages that provide estimated costs with FY17 rates soon.

Managed Workstation H: and I:\groups troubles

On 6/15/2016, we experienced a significant incident where the server infrastructure behind H:\ and I:\groups was unable to accept new connections. The cause of that incident is now understood. We applied a workaround of moving the 90% of file directories that were affected by this incident to new server infrastructure, which was already in use for 10% of our file directories. As mentioned at the time, we were hesitant to make that change because we weren’t fully confident that the new server infrastructure was ready for a bigger load, but at the time it appeared to be the quickest and best way to restore service.

Since then, we’ve had a series of incidents that were smaller in scope. This is because one of the 4 new servers continues to have problems, which seems to be tied to something that happens in the very early morning. The other 3 new servers don’t experience these same problems, and the incidents since 6/15 have only affected the same set of customers that leverage the 1/4 of file directories hosted by that one server. Those recurring incidents do not prevent new connections like the 6/15 incident, instead there is a slow degradation of performance to the point where it is very noticeable. The eOutage messages sent about those incidents have been pretty generic, so we thought it important to provide more detail than what has been communicated via eOutage.

We recognize that these continuing problems are impactful and undesirable, and continue to work hard to identify what is causing those problems and to seek solutions.

As we explore solutions we are also trying to limit any undesirable impacts from changes, but we recognize that moving too slowly isn’t acceptable. As we try to move quickly, we are making some changes that we’d normally move more slowly on, with more customer notification.

We really appreciate your patience with us, and please know that we continue to work hard to provide a reliable service that meets your needs.

OUTAGE: H:, I:\groups, i:\snapshots

We are in the process of applying a workaround to resolve this incident.

The workaround involves a change we had planned to make in the future to upgrade the server infrastructure behind these file services. We’ve moved one large customer over to this new infrastructure already, and had planned to move another before moving all customers. That timeline is accelerating to now because the new server infrastructure is not affected by the cause of this incident.

One of the reasons we had wanted a slower timeline was to ensure we had settings tuned and adequate capacity to minimize the impact of this change. So there may be some minor issues after we’ve finished swinging everything over to the new server infrastructure, which we’ll address as issues arise.

In our initial testing of this change, we’ve seen that some client computers need a reboot to figure out the new underlying server location. In our testing that was around 10% of client computers, and is tied to information cached on the client computer so isn’t something we can easily be fixed other than with a reboot.

Group directories (i:\groups) are in the process of being moved now and should be available again in the next 15 to 30 minutes. Home directories will be moved after that, but there is another incident with a service we depend on which may affect our ability to quickly redirect home directories. So at this time, we don’t have an ETA for restoration of home directories.

 

Disabling Nebula2 user accounts

We have begun disabling unused NEBULA2 user accounts.

 

This does not relate to eligibility groups, nor will it result in the loss of any Nebula services – it is only about whether your NEBULA2 user account is enabled or disabled.

 

What and when:

The disabling of unused NEBULA2 accounts begins today. If your NEBULA2 account hasn’t been used in more than 37 days, it will be disabled.

 

What you need to do:

If your NEBULA2 account has not been used recently, this is a courtesy notice. If, for some reason, you still need your NEBULA2 user account, you can re-enable your account by going to the UW Groups Service at:

https://groups.uw.edu/group/3b253114a3444fe5a5f7d1f5d9bc831a/member,

 

Follow the steps below:

  1. In the “Add members” box type in your UW NetID
  2. Click on “Do it”

 

Your NEBULA2 account will be re-enabled within 1 hour and it will have the same password as it did previously.

 

More info:

For more information, please refer to https://it.uw.edu/wares/nebula/adding-users/nebula2-user-disables/

 

If you have any questions or concerns, please contact the UW-IT Service Center via help@uw.edu.

 

RE: Microsoft Infrastructure documentation migration/consolidation

I’m back to report that this work is complete. All www.netid.washington.edu pages have a redirect to the new IT Connect location. If you have bookmarks or links to www.netid pages, you can now update them.

 

Here is an orientation for the refactored documentation site:

  • Use of UWWI has been replaced. ‘UWWI user’ and ‘UWWI group’ has been replaced with NETID user and NETID group. Exceptions include a few pictures (hunting down source files) and references which are out of our direct control (e.g. the UW NetID Support Tool still uses “UWWI” so our documentation must continue to reflect that). Feel free to let us know about “UWWI” instances you think we missed. J
  • The Communications page notes how to get ahold of us for urgent issues, and introduces the service mailing lists and how to subscribe or unsubscribe. Child pages include an index of all the MI service documentation (including pages not in IT Connect), all service newsletters, and all service notifications (since 2012). In addition to being an archive, this provides a different way for service customers to keep in touch—instead of being on this mi-announce mailing list, you can monitor that location instead. I’d stress that the index page is a good way to find things quickly.
  • The Service Design page includes capability maps that outline what we provide and our thoughts about the future, the architecture guide, and policy documents. This is mostly content that IT staff might need to reference to find out how the service is designed. Some of this content has gotten minor updates, and I’ve noted gaps for future documentation. Documenting our Entra ID integration is the most notable gap.
  • The Other Help page includes content which is only indirectly related to the MI service. These are typically topics for which we are the subject matter experts for or where additional explanation or background will help the UW community. The venerable ‘Windows domain setup at UW’ document is a good example of the type of document here. Clearly separating these documents provides a clearer expectation boundary about how these documents relate to the MI service. The FAQ is under here and has gotten a topical re-organization and some pruning. If you haven’t seen the extensive Entra ID terminology part of that FAQ, it’s worth a look.
  • And then the rest of the top-level pages are aligned with the capabilities the MI service provides: Software, Authentication integration, Entra ID, and Delegated OUs.

 

Brian Arkills

Microsoft Infrastructure Service Manager

UW-IT

 

 

From: Brian Arkills Sent: Thursday, April 28, 2016 3:15 PM To: ‘mi-announce@uw.edu’ <mi-announce@uw.edu> Subject: Microsoft Infrastructure documentation migration/consolidation

 

We’re combining our documentation into IT Connect. A few exceptions that don’t work well on that platform will remain in the UW-IT Wiki.

 

What and When:

Over the next several weeks, we will be migrating the Microsoft Infrastructure documentation into IT Connect (https://it.uw.edu). Our documentation will live under https://it.uw.edu/wares/msinf/.

 

Our content has been splattered across multiple locations, including a web hosting platform we run for ourselves. It doesn’t make sense for us to run something separate, and consolidating on IT Connect should improve discoverability of that content.

 

Related to the service rename previously announced, we’ve already moved most of the content that was previously in the UW-IT wiki space named UW Windows Infrastructure to the IT Connect location noted above.

 

What You Need to Do:

This notice is partly advisory so you know to expect some changes, but you may also have an action to take.

 

If you host links to our content or have bookmarked pages, you may want to update them. Where we can, we’ll put in page redirects to the new location and maintain those old pages for 3 months to facilitate this. Because this documentation migration is not complete and will span a couple week period, we’ll send another note when we’re done so you know when to do that activity.

 

More Information:

Unfortunately, not all of our content can move to IT Connect. A few things will need to be on the UW-IT Wiki platform. We’ll clearly link to those pages, have navigation aids from those pages back to IT Connect, and clearly note that this wiki space is an ancillary location. That ancillary UW-IT Wiki space is https://wiki.cac.washington.edu/display/MSINF/Microsoft+Infrastructure, and it’ll have things like request forms, the public proposals with analysis we’ve previously shared, and other documents with flexible editing needs.

 

The web location www.netid.washington.edu will retire in about 3 months. It served us nicely for 10 years. J

 

Brian Arkills

Microsoft Infrastructure Service Manager

UW-IT

 

20150929: Entra ID Help Desk Card

The Entra ID Help Desk Card is being implemented to help ensure users have an easy way to get assistance.

 

What and When:

Today the Help Desk Card capability in our Entra ID tenant is being enabled. When users click on the help icon in applications which support this, they’ll be presented with contact information which can allow them to easily get help.

 

The following information will be present:

UW IT

+1 (206) 221-5000

help@uw.edu

http://www.washington.edu/itconnect  

 

What You Need to Do:

Nothing, this notice is informational only so you aren’t surprised by the change.

 

More Info:

Please refer to https://support.office.com/en-US/client/results?Shownav=true&lcid=1033&ns=O365ENTADMIN&version=15&ver=15&services=INTUNE_O365%2cYAMMER_EDU%2cSHAREPOINTWAC_EDU%2cMCOSTANDARD%2cSHAREPOINTSTANDARD_EDU%2cEXCHANGE_S_STANDARD&HelpID=O365E_CustomHelpDesk for more information about this capability.

 

Brian Arkills

UW Windows Infrastructure Service Manager

 

20151102: Certificate services for delegated OUs

The UW Windows Infrastructure has deployed a public key infrastructure consisting of a 2 tier certificate authority, whose initial purpose is to provide automatic certificate enrollment and certificate deployment for delegated OU computers running Windows.

 

What and When:

On 10/16/2015, UWWI deployed an Active Directory published root certificate authority named netid-root-CA. Being AD published means that domain-joined computers trust it by default.

 

On 10/23/2015, UWWI deployed an Active Directory integrated issuing certificate authority named netid-issuing-CA. Being AD integrated means that:

  • domain-joined computers trust it by default,
  • domain users and computers can request and retrieve certificates from it, leveraging the secure channel trust already in place
  • issued certificates can be published to the appropriate AD object (which enables a variety of uses)
  • certificate revocation lists are published to AD, enabling domain-joined computers to reliably determine whether a given certificate is still valid

 

Like the UW Services CA, these certificate authorities are not publicly trusted. This limits their usefulness to UW internal purposes—for example, you wouldn’t use this CA to enable HTTPS for a public website.

 

In the near future, on a per OU basis, we’ll provide a group which OU admins will be member managers for. You can add computers as members to this group to direct them to automatically enroll for a “Computer” certificate, with client authentication and server authentication uses. Unlike most other certs you’ve used, these certs automatically get renewed, and require no further human involvement. More details on the nature of these certs is available below. More details on this coming capability will be shared when this is ready.

 

What You Need to Do:

At this time nothing. We wanted to let security conscious customers know that we changed the certificate authority trust of domain-joined computers intentionally as part of a planned release. We’ve mentioned this intention several times over the last year, and the deployment of capabilities is now approaching.

 

We’ll let you know when we have enabled this new capability for your OU. At that time, you can add computers to a group and get automatic certificate enrollment to these computers.

 

More Info:

This capability was added due to strong customer interest in lowered costs for certificate management. Based on customer need analysis, there were enough internal-only uses and cost-savings to move forward, even though this may make the UW certificate story a little more complicated. Given how handy an AD integrated CA is, we believe there will be more use cases identified and future capabilities–in fact, there is currently customer interest in exploring three other use cases. More information on these use cases and future capabilities will be coming over the next few months.

 

Do be aware that for UW internal use cases you may need to ask a service to trust the netid-root-CA and netid-issuing-CA in order to leverage the client authentication capability. For example, the Groups Web Service does not currently trust these certificates.

 

If you need to get a copy of the CA certs, they are available at:

http://thrawn.uw.edu/CertEnroll/cracken.netid.washington.edu_netid-issuing-CA.crt

http://thrawn.uw.edu/CertEnroll/madine.netid.washington.edu_netid-root-CA.crt

 

Additional details on the “Computer” certificate:

Validity: 1 year

Renewal: 6 weeks

Private key is not exportable

Minimum key size of 2048

Subject name is based on dnsHostname attribute of AD computer object

 

Additional technical details on the two new certificate authorities:

Both are implemented in a manner such that if we later needed to, we can meet FIPS compliance, although at this time we are not using a HSM module for private key storage. The root CA is designed to be an “offline” CA hosted in Azure, brought online at least once a year to republish the certificate revocation list (CRL). Hosting this CA in Azure allows us to save costs since it is offline most of the time, and their hosting practices are as good or better than ours (e.g. they have rolling audits to meet various regulatory certifications). We are hoping that in the future Microsoft provides a virtual HSM capability for AD-CS integrated with its Azure Key Vault.

 

Brian Arkills

UW Windows Infrastructure Service Manager

20151218: New domain GPO

A new group policy object at the root of the NETID domain is being created. This GPO will only apply to computers which are opted into applying it.

 

What and When:

Today UWWI will create a new GPO called ‘AD-CS Auto-enrollment’ at the domain root.

 

This GPO will enable auto-enrollment for the certificate services client. This GPO will only apply to computers which:

  1. Are members of the group u_windowsinfrastructure_adcs_autoenroll
  2. Do not have GPO inheritance blocking.

 

What You Need to Do:

Nothing. There is no immediate impact to you.

 

At this time, none of your computers are affected. You may choose to opt your computers into this as part of the emerging Active Directory Certificate Services (AD-CS) service option. More on this is forthcoming.

 

More Info:

The specific setting in this GPO is:

Computer/Policies/Windows Settings/Security Settings/Public Key Policies/Certificate Services Client – Auto-Enrollment Settings/

Automatic certificate management=Enabled

Enroll new certificates, renew expired certificates, process pending certificate requests and remove revoked certificates=Enabled

Update and manage certificates that use certificate templates from Active Directory=Enabled

 

Enabling this client computer setting is required to provide the AD-CS service option with auto-enrollment. We’ve purposely scoped this change so you retain management of your computers; you need to take an action for this computer configuration to affect you. Our goal is to respect your autonomy in how you manage your computers. However, it makes a lot of sense to have a single toggle which enables a desired outcome, so we’ve designed this mechanism in such a way that your intention and the desired outcome is directly connected.

 

Put in a more concrete way, in the future, you may choose to have some of your computers automatically get a certificate by adding them to a group. By adding them to this group, you’ll be allowing this GPO to configure the client-side setting and allow access to a specific certificate template. The end result will be that those computers will automatically end up with a certificate. J

 

If you have computers in an OU which blocks inheritance, there are workarounds that are in our customer documentation, so no worries.

 

We’re pretty close to releasing this new service option, and will be sending a little more info to the uwwi-discuss@uw.edu mailing list for eager folks to kick the tires. You can expect further details here soon. For your benefit, below I’ve included the prior change we made to enable this emerging service option.

 

If you have questions about this change, please send an email to help@uw.edu with “UWWI AD-CS autoenrollment change” in the subject line.

 

Brian Arkills

UW Windows Infrastructure Service Manager

UW-IT

 

From: Brian Arkills Sent: Monday, November 2, 2015 1:09 PM To: ‘uwwi-announce@uw.edu’ <uwwi-announce@uw.edu> Subject: Certificate services for delegated OUs

 

The UW Windows Infrastructure has deployed a public key infrastructure consisting of a 2 tier certificate authority, whose initial purpose is to provide automatic certificate enrollment and certificate deployment for delegated OU computers running Windows.

 

What and When:

On 10/16/2015, UWWI deployed an Active Directory published root certificate authority named netid-root-CA. Being AD published means that domain-joined computers trust it by default.

 

On 10/23/2015, UWWI deployed an Active Directory integrated issuing certificate authority named netid-issuing-CA. Being AD integrated means that:

  • domain-joined computers trust it by default,
  • domain users and computers can request and retrieve certificates from it, leveraging the secure channel trust already in place
  • issued certificates can be published to the appropriate AD object (which enables a variety of uses)
  • certificate revocation lists are published to AD, enabling domain-joined computers to reliably determine whether a given certificate is still valid

 

Like the UW Services CA, these certificate authorities are not publicly trusted. This limits their usefulness to UW internal purposes—for example, you wouldn’t use this CA to enable HTTPS for a public website.

 

In the near future, on a per OU basis, we’ll provide a group which OU admins will be member managers for. You can add computers as members to this group to direct them to automatically enroll for a “Computer” certificate, with client authentication and server authentication uses. Unlike most other certs you’ve used, these certs automatically get renewed, and require no further human involvement. More details on the nature of these certs is available below. More details on this coming capability will be shared when this is ready.

 

What You Need to Do:

At this time nothing. We wanted to let security conscious customers know that we changed the certificate authority trust of domain-joined computers intentionally as part of a planned release. We’ve mentioned this intention several times over the last year, and the deployment of capabilities is now approaching.

 

We’ll let you know when we have enabled this new capability for your OU. At that time, you can add computers to a group and get automatic certificate enrollment to these computers.

 

More Info:

This capability was added due to strong customer interest in lowered costs for certificate management. Based on customer need analysis, there were enough internal-only uses and cost-savings to move forward, even though this may make the UW certificate story a little more complicated. Given how handy an AD integrated CA is, we believe there will be more use cases identified and future capabilities–in fact, there is currently customer interest in exploring three other use cases. More information on these use cases and future capabilities will be coming over the next few months.

 

Do be aware that for UW internal use cases you may need to ask a service to trust the netid-root-CA and netid-issuing-CA in order to leverage the client authentication capability. For example, the Groups Web Service does not currently trust these certificates.

 

If you need to get a copy of the CA certs, they are available at:

http://thrawn.uw.edu/CertEnroll/cracken.netid.washington.edu_netid-issuing-CA.crt

http://thrawn.uw.edu/CertEnroll/madine.netid.washington.edu_netid-root-CA.crt

 

Additional details on the “Computer” certificate:

Validity: 1 year

Renewal: 6 weeks

Private key is not exportable

Minimum key size of 2048

Subject name is based on dnsHostname attribute of AD computer object

 

Additional technical details on the two new certificate authorities:

Both are implemented in a manner such that if we later needed to, we can meet FIPS compliance, although at this time we are not using a HSM module for private key storage. The root CA is designed to be an “offline” CA hosted in Azure, brought online at least once a year to republish the certificate revocation list (CRL). Hosting this CA in Azure allows us to save costs since it is offline most of the time, and their hosting practices are as good or better than ours (e.g. they have rolling audits to meet various regulatory certifications). We are hoping that in the future Microsoft provides a virtual HSM capability for AD-CS integrated with its Azure Key Vault.

 

Brian Arkills

UW Windows Infrastructure Service Manager