Mark Minasi's Tech Forum
Register Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
Protech

Avatar / Picture

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 46
Reply with quote  #1 
Hi guys,

I have noticed that on Server 2016, it can take a long time after you login to actually get to the desktop. It seems to hang at the "Please wait for user profile service" for a long time (20 mins).

Any thoughts?

Cheers

Dave


0
Pieter

Avatar / Picture

Senior Member
Registered:
Posts: 228
Reply with quote  #2 
Is this a Virtual machine ?  I've noticed that too for the first, and only the first, logon. Actually I think the delay was before the CTRL+ALT+DEL screen. Not quite the same.

Do you use Roaming Profiles ?  Profile too big ? Network slow ?

Just tested a couple of Win2016 servers (RDP to VM on Hyper-V) : always less than 10 seconds.
 

__________________
Pieter Demeulemeester
0
Protech

Avatar / Picture

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 46
Reply with quote  #3 

Hi,

Yes it is a VM. There are no roaming profiles. I don't think the network is slow, but i'm open to suggestions on how to eliminate the network. I have seen similar in the past it is usually that something (a service) is waiting to time out, although i don't know what.
Way back there used to be a Microsoft app that tracked boot/login time so you could see where delays were but I don't know that it exists anymore.

Maybe it's just the way it is. It is a DC, but the network only has about 10 users.

Not sure whatr to try next.

Cheers

D

0
Pieter

Avatar / Picture

Senior Member
Registered:
Posts: 228
Reply with quote  #4 
>> Microsoft app that tracked boot/login time
Maybe you mean Sysinternals Process Monitor https://docs.microsoft.com/en-us/sysinternals/downloads/procmon :
"Boot time logging of all operations"

>> Maybe it's just the way it is.
Definitely not. My DC's are also virtual. Boot and logon takes seconds.

> It is a DC,
So you don't need network connectivity to logon. User+password will be validated on the server where you're logging onto.

Anti-virus ?
Still slow after logon ? Does TaskMgr reveals something ?
Add more CPU or RAM ?

__________________
Pieter Demeulemeester
0
cj_berlin

Avatar / Picture

Senior Member
Registered:
Posts: 297
Reply with quote  #5 
Quote:
Originally Posted by Pieter

> It is a DC,
So you don't need network connectivity to logon. User+password will be validated on the server where you're logging onto.


That's if you've got DNS right, i.e. if 127.0.0.1 is on the list of DNS servers. And that's exactly what I would be looking into, *especially* if it's the only DC in that domain.

What about network shares? Can you get to SYSVOL immediately after rebooting the DC?

__________________
Evgenij Smirnov

My personal blog (German): http://www.it-pro-berlin.de/
My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/
0
Donato

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 24
Reply with quote  #6 
"Still slow after logon ? Does TaskMgr reveals something ?
Add more CPU or RAM ?"

If it's still slow after you get to the desktop, make sure that the virtual memory is set to system managed.

Are we talking about the administrator login? Is the administrator login & password the same as the network login?
0
Protech

Avatar / Picture

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 46
Reply with quote  #7 

Hi Guys,

To answer your comments:


-DNS to 127.0.0.1? The Server's DNS settings do point to it's own IP address, which is effectivly the same thing.
-Server has plenty of RAM.
-Network runs at 1Gb
-No roaming profiles
-Local profile very small
-Server (+sysvol) is accesable as soon as Server is up. It's just the login to the VM itself which is slow after a reboot
-Admin login and password is the domain admin one
-When you finally get to the desktop it's fine


Will try out Process Monitor when I can. Not used that before.

Cheers

0
cj_berlin

Avatar / Picture

Senior Member
Registered:
Posts: 297
Reply with quote  #8 
Quote:
Originally Posted by Protech

-DNS to 127.0.0.1? The Server's DNS settings do point to it's own IP address, which is effectivly the same thing.


No, it isn't, even if it appears irrelevant for the problem at hand based on your last post.

Own IP address will NOT work if the NIC is down - which on some 802.1X enabled networks I've seen can be for a couple of minutes after the light actually goes on. 127.0.0.1 works even if you pull the cable.

User Profile service and Group Policy service log stuff, maybe there are some clues there.

__________________
Evgenij Smirnov

My personal blog (German): http://www.it-pro-berlin.de/
My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/
0
Pieter

Avatar / Picture

Senior Member
Registered:
Posts: 228
Reply with quote  #9 
>> DNS to 127.0.0.1
I even think that's the default for Win2016 DC's. Dcpromo sets it that way.



__________________
Pieter Demeulemeester
0
Protech

Avatar / Picture

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 46
Reply with quote  #10 
Thanks guys,

Never seen the issue relating to 127.0.0.1 tbh.

Still working on this issue and will report back. 
0
spam spam bacon spam

Avatar / Picture

Still Checking the Forum Out
Registered:
Posts: 7
Reply with quote  #11 
Holy crap, I can actually contribute something (positive) here...

Here are some tidbits about IP addresses ~ specifically the differences between 127.0.0.1* and the typical local IP address (i.e.: 192.168.x.x, 10.x.x.x, 172.16.x.x)
 
________________________________________________________________

127.0.0.1 is the address for the locally installed TCP/IP stack.

    It's technical name is "localhost."

    In IPv6, it's ::1/128

    When TCP/IP is installed (correctly), you always have this address available, even when the machine has no
    NICard whatsoever.  Pretend for a second that you rip out the NICard from your PC, and use it as a shim under
    the wobbly leg of your desk... you'd still be able to ping 127.0.0.1.

    PING 127.0.0.1 when you want to see if the TCP/IP stack is installed correctly.


________________________________________________________________

10.x.x.x, 172.16.x.x, 192.168.x.x are technically called the "link-local" address.

    This is the address assigned to the NICard.
    
    In IPv6, it's fe80:/10

    PING your own link-local address to see if the NICard is working correctly.

________________________________________________________________

Fun fact: your link-local address is actually your machine's own default gateway.  

Traffic coming from inside your machine which needs to get off your machine, is actually routed to your own IP address ~ so your own IP address is actually a "first-hop" for traffic intended to go to another machine.

When it reaches your NICard, it's encoded for the media type (copper, wireless, etc) and shoved out the hole, screaming all the way like a 1st time parachutist who has just realized they are petrified of heights, planes and open spaces.          


Cheers,

~spammy

PS- In case you forgot, it's all yer' damn fault I know this crap.
Pffffffttttthhhhht [wink]~


________________________________________________________________
________________________________________________________________


*We all use "127.0.0.1", but actually, we can use any address from 127.0.0.1 thru 127.255.255.254.
This is because 127.0.0.0 is a /8 network, formerly known as a Class A network.  Vint Cerf (Vintie!) designed the 32 bit addressing scheme for IP, and decided to use the first 8 bits for the network portion and the 24 bits that followed for the individual device.  Thus, a whopping total of 256 networks was born, with each network having 16,777,216 addresses (or, more technically, a f***load).

Those original networks were numbered from 000.x.x.x thru 255.x.x.x
Ironically, "127.x.x.x" was NOT reserved (nor assigned) during this infancy stage.

Fast forward to September 1981 when those 256 networks were broken down into Class A, B, C (& "other") networks ~ done in order to create more networks.

At the time of this modification, only networks 001.x.x.x thru 041.x.x.x had been assigned.  042.x.x.x thru 254.x.x.x were available for new assignment.   

The decision was to break the original 256 networks into 4 clumps, using the octet borders as the dividers.

As a result, the first clump included 0.0.0.0/8 thru 127.225.255.255/8 and was named "Class A." The second clump went from 128.0/16 thru 191.255/16 and was named "Class B", and so on.

THIS is when the entire 127.0.0.0/8 network was reserved, making it un-assignable.  It was then dedicated to the locally installed TCP/IP stack.  It became common to just pick the first address of that entire network, 127.0.0.1, to test the TCP/IP stack.   However, you can use any IP address in that network, and the results will be the same.



__________________
If at first you don't succeed, destroy all evidence that you tried.

0
spam spam bacon spam

Avatar / Picture

Still Checking the Forum Out
Registered:
Posts: 7
Reply with quote  #12 
I went digging around the 'toobs and learned a few things about this issue...

It seems like DNS and/or network bindings is a common culprit when this happens, but Microsoft does offer a patch for Server 2012 that relates to password inconsistency.

#1 is super easy, so I'd try that one and if it doesn't work, submit a request for vacation starting tomorrow. (hahaha)



1.  If the server is multihomed, make sure your "production" card is on top:
     network connections -> advanced settings -> adapters and bindings.


2.  https://support.microsoft.com/en-us/help/3132080/the-logon-process-hangs-at-the-welcome-screen-or-the-please-wait-for-t

I've pasted the pertinent info below:

Quote:

When a user logs on to a computer, either directly on a client computer or through a remote desktop connection, the logon process may hang at the "Welcome" screen or the "Please wait for the User Profile Service" error message window.

When this issue occurs, the user's current password does not match the password that is cached in Credential Manager. This issue can occur immediately after the user or an administrator performs a password change. It can also occur after some time has passed after the password change.

The following configurations are known to contribute to this issue:

  • The user has a mapped home folder to a Distributed File System (DFS) path, such as \\contoso.com\homefolders\user.
  • The user has enabled the "Set a default associations configuration file" Group Policy Object for file association sets. Also, the XML is stored in a DFS path, such as \\contoso.com\netlogon.
  • The user has GPP for Drive Maps that map a folder in a DFS path, such as \\contoso.com\data1.

Cause

This issue occurs because of a deadlock between Credential Manager and the Redirector (RDR) and Data Protection API (DPAPI).





HTH,

~spamster

 


__________________
If at first you don't succeed, destroy all evidence that you tried.

0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.