Windows 10 does not look to start service until logon

2456

Answers

  •  fyi I am having the same issue on windows 7 ultimate 64bit - so is suspect it has nothing to do with windows 10.......

  • To be a little more clear....

     

    I have a win10 and a win7 machine, both running the same version of teamview (12.0.77242) and both having "start teamviewer with windows" and "Full access control when a partner is connecting to the windows logon screen"

    If i try to connect to the win7 machine (that is sitting at the windows login prompt) from the win 10 machine it CANNOT connect.

     If i try to connect to the win10 machine (that is sitting at the windows login prompt) from the win 7 machine it DOES connect.

     

     

  • I downgraded the teamview on the win7 machine and that did not fixe the problem -

     

    so its like its not a win 10 problem and its not a teamviewer problem - so it must be a config problem ???

  • JedenTag
    JedenTag Posts: 38 ✭✭

    I haven't been having any trouble with TeamViewer 12 and Windows 10 when using this script linked here:

    https://community.teamviewer.com/t5/TeamViewer-12/Unable-to-connect-to-TeamViewer-ID-LAN-only/m-p/6288#M2448

    Add the following outgoing firewall rules in Windows 10... you can do so by running the following in an elevated PowerShell window:

    New-NetFirewallRule -DisplayName "!Allow Outbound UDP svchost.exe" -Enabled True -Direction Outbound -Profile ANY -Protocol UDP -Program "C:\WINDOWS\system32\svchost.exe" -Action Allow -Description "Allows Outbound UDP svchost.exe."
    New-NetFirewallRule -DisplayName "!Allow Outbound TCP TeamViewer_Service.exe" -Enabled True -Direction Outbound -Profile ANY -Protocol TCP -Program "%ProgramFiles% (x86)\TeamViewer\TeamViewer_Service.exe" -Action Allow -Description "Allows Outbound TCP TeamViewer_Service.exe."
    New-NetFirewallRule -DisplayName "!Allow Outbound 5938 UDP TeamViewer_Service.exe Local Port" -Enabled True -Direction Outbound -Profile ANY -LocalPort 5938 -RemotePort ANY -Protocol UDP -Program "%ProgramFiles% (x86)\TeamViewer\TeamViewer_Service.exe" -Action Allow -Description "Allows Outbound TeamViewer_Service.exe communication via 5938 UDP."

     

  • Mulsambe
    Mulsambe Posts: 8 ✭✭

    Here are additional information from my PC :

    • Are the PCs in a domain (I think that was already answered as "doesn't matter")?
      • NO
    • Did you configure the PCs in any special way to be able to join your network or do you have anything in your LAN that blocks unknown devices?
      • NO
    • Please check the firewall (local and hardware firewall, if available) for error messages / ports being blocked / etc. for destination *.teamviewer.com. Is there anything being blocked? And if so, why?
      • Nothing of this type
    • Are there any port limitations for local ports of outgoing connections (for example: only allow port starting at 32765, or similar)?
      • No limitation
    • Please check the output of the following two commands and post them here if they don't match the expected values:
      1) netsh int ipv4 show dynamicportrange tcp
      2) netsh int ipv4 show excludedportrange tcp
      The first command should show a starting port of around 49152 and a total count of about 16384.
      The second command should show an empty list.
      • First command OK
      • Second command : shows port 19455-19455
    • Run autoruns (https://technet.microsoft.com/de-de/sysinternals/bb963902.aspx) and check the Winsock Providers and Network Providers tab. Is there anything in there?
      • Network providers : empty
      • Winsock providers : shows 2 entries :
        mdnsNSP    Bonjour Namespace Provider    Apple Inc.    c:\program files (x86)\bonjour\mdnsnsp.dll   
        mdnsNSP    Bonjour Namespace Provider    Apple Inc.    c:\program files\bonjour\mdnsnsp.dll   
  • chrullrich
    chrullrich Posts: 14 ✭✭

    Well, I think I know what happens, but I have no idea why.

    This is an excerpt from a WFP event capture on 1703:

    <netEvent>
    <header>
    <timeStamp>2017-05-09T22:12:26.351Z</timeStamp>
    <flags numItems="9">
    <item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>
    <item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>
    <item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>
    <item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>
    <item>FWPM_NET_EVENT_FLAG_REMOTE_PORT_SET</item>
    <item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>
    <item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>
    <item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>
    <item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
    </flags>
    <ipVersion>FWP_IP_VERSION_V4</ipVersion>
    <ipProtocol>6</ipProtocol>
    <localAddrV4>192.168.92.134</localAddrV4>
    <remoteAddrV4>192.168.92.6</remoteAddrV4>
    <localPort>49950</localPort>
    <remotePort>3128</remotePort>
    <scopeId>0</scopeId>
    <appId>
    <data>5c006400650076006900630065005c0068006100720064006400690073006b0076006f006c0075006d00650034005c00700072006f006700720061006d002000660069006c00650073002000280078003800360029005c007400650061006d007600690065007700650072005c007400650061006d007600690065007700650072005f0073006500720076006900630065002e006500780065000000</data>
    <asString>\.d.e.v.i.c.e.\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.4.\.p.r.o.g.r.a.m. .f.i.l.e.s. .(.x.8.6.).\.t.e.a.m.v.i.e.w.e.r.\.t.e.a.m.v.i.e.w.e.r._.s.e.r.v.i.c.e...e.x.e...</asString>
    </appId>
    <userId>S-1-5-96-0-2</userId>
    <addressFamily>FWP_AF_INET</addressFamily>
    <packageSid>S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523</packageSid>
    <enterpriseId/>
    <policyFlags>0</policyFlags>
    <effectiveName/>
    </header>
    <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
    <classifyDrop>
    <filterId>66432</filterId>
    <layerId>48</layerId>
    <reauthReason>0</reauthReason>
    <originalProfile>3</originalProfile>
    <currentProfile>3</currentProfile>
    <msFwpDirection>MS_FWP_DIRECTION_OUT</msFwpDirection>
    <isLoopback>false</isLoopback>
    <vSwitchId/>
    <vSwitchSourcePort>0</vSwitchSourcePort>
    <vSwitchDestinationPort>0</vSwitchDestinationPort>
    </classifyDrop>
    </netEvent>

    This is the TeamViewer service attempting an outbound connection to an HTTP proxy. The attempt fails, as can be seen from the FWPM_NET_EVENT_TYPE_CLASSIFY_DROP.

    The event references the filter rule with ID 66432. This is it:

    <item>
    <filterKey>{9a00657e-fe37-47c1-818c-f643513fc2fe}</filterKey>
    <displayData>
    <name>Block Outbound Default Rule</name>
    <description>Block Outbound Default Rule</description>
    </displayData>
    <flags/>
    <providerKey>{4b153735-1049-4480-aab4-d1b9bdc03710}</providerKey>
    <providerData>
    <data>6000000000000000</data>
    <asString>`.......</asString>
    </providerData>
    <layerKey>FWPM_LAYER_ALE_AUTH_CONNECT_V4</layerKey>
    <subLayerKey>{b3cdd441-af90-41ba-a745-7c6008ff2300}</subLayerKey>
    <weight>
    <type>FWP_EMPTY</type>
    </weight>
    <filterCondition numItems="1">
    <item>
    <fieldKey>FWPM_CONDITION_ALE_PACKAGE_ID</fieldKey>
    <matchType>FWP_MATCH_NOT_EQUAL</matchType>
    <conditionValue>
    <type>FWP_SID</type>
    <sid>S-1-0-0</sid>
    </conditionValue>
    </item>
    </filterCondition>
    <action>
    <type>FWP_ACTION_BLOCK</type>
    <filterType/>
    </action>
    <rawContext>0</rawContext>
    <reserved/>
    <filterId>66432</filterId>
    <effectiveWeight>
    <type>FWP_UINT64</type>
    <uint64>549755813888</uint64>
    </effectiveWeight>
    </item>

    This rule applies whenever its single condition matches. The condition is that the "package ID" of the packet's (actually, the connection's) originator is not S-1-0-0 (no identity), or in other words, it matches everything that has a package ID.

    In the event trace, we see that the TeamViewer service process has a package ID, wherever it may have acquired it, hence it matches this rule and its traffic is blocked.

    I have no idea where the rule comes from (except that it is a Windows Firewall rule per its provider ID) or what it may be intended to do. My current guess is that "modern" apps are not supposed to communicate when no user is logged on.

    I cannot prove that this is any different on 1607, because apparently WFP captures do not include permitted packets. According to Process Explorer, the service process has no application package SID in either version.

  • chrullrich
    chrullrich Posts: 14 ✭✭

    chrullrich wrote:

    In the event trace, we see that the TeamViewer service process has a package ID, wherever it may have acquired it, hence it matches this rule and its traffic is blocked.

     From the WFP trace:

    <packageSid>S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523</packageSid>

    From the list of app containers:

    Container:
    SID: S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523
    Name: microsoft.windows.fontdrvhost
    Display name: Usermode Font Driver Host

    That is clearly the same SID. So how does the TeamViewer service get stuck with the "font driver host"'s package identity?

  • Maurice
    Maurice Posts: 10 Staff member 🤠

    @chrullrich That's a very interesting bit of information. The fact that the service is using the SID  of a different user is definitely not correct if there's no user logged in. We will fix that but before that could you test if that would solve the problem?

    To test it you need to disable the Windows Firewall service.

    Maurice
    Software Developer
  • chrullrich
    chrullrich Posts: 14 ✭✭

    @Maurice, yes, with the service disabled, the computer shows up immediately after rebooting, and I can connect to it.

    Also, there is plenty of other evidence that the firewall is interfering: The TV log says something about "connection failed" due to "bad access", the Security event log is full of events 5152 (firewall blocked packet) and 5157 (firewall blocked connection), both referring to teamviewer_service.exe, and my network trace clearly shows that the connection attempts do not reach the switch.

    Please be aware that this SID is not a user SID, and is not used as one by the firewall. An application package identifier is a SID that is used for sandboxing processes, both "modern" apps and such others as opt in to this protection. As the name says, it identifies an application, not a user.

  • mandfmike
    mandfmike Posts: 18 ✭✭

    I turned the windows firewall service off on one of my computers with windows 10 1703 on the domain and rebooted. It did show up on the list and I was able to log in to it like normal unattended access. Turned windows firewall service back on, rebooted and can't access it until someone logs in.

  • Bradb21
    Bradb21 Posts: 1

    I've upgraded a couple machines to 1703 and one machine is fine and the other never appears in my console after boot. I've noticed the service does not start, and so far I've been able to fix it by setting the service to "delayed start" and it then appears in my console as online automatically. I had to have a user manually start it on the other end every time.

  • hubran
    hubran Posts: 3

    For me this didn't work. It doesn't make any difference whether the Windows firewall is stopped or running, only after someone is logged on (either locally or remote via rdp) the machine shows up as online under TV computer and contacts.

    It is w10-x64 v1703 updated from v1607

  • TimCFT
    TimCFT Posts: 6

    Confirmed here too. I had previously tried turn off the firewall in the GUI with no effect, but disabling the service shows the workstation online immediately after reboot, without user interaction.

    I've tried turning off the firewall in the GUI for each connection type in turn (in case it wasn't immediately identifying as a domain connection, etc) and for all three at once, but only disabling the service has the desired effect.

  • TimCFT
    TimCFT Posts: 6

    Hopefully TeamViewer can confirm that they are working on a fix for this, or talking to Microsoft? As disabling the FW is obviosuly not an option and TV is therefore not currently fit for purpose.

  • mandfmike
    mandfmike Posts: 18 ✭✭
    edited January 2023

    I disabled the Windows Firewall service and it is available after reboot without anyone having to log in. I didn't use the firewall GUI. When I re-enabled the Windows Firewall Service and rebooted, I was back to having to have someone login or RDP to the machine.

    Why can't TeamViewer come up with a solution? I bet **Third Party Product** doesn't have this problem.

  • mandfmike
    mandfmike Posts: 18 ✭✭

    I agree, teamviewer should of had this problem fix by now. I know they said none of their machines have this problem when they rolled Win10 1703. I find that hard to believe when I installed it on 5 computers and I have this problem on all 5. I rely on unattended access several times DAILY. I would be forced to switch to a more reliable solution very soon. Guess time to start looking for an alternative at least.

  • Basically Teamview people do not care. That is obvisous.

    Our response is also obvisou, to find another provider who does offer functionality you would expect t find in a v0.0.0.01 of a product.that is not present is Teamviewer.

    Can any suggest altenratives? Let use their messeaging system to find a competitor.....

  • hubran
    hubran Posts: 3
    The latest build offered by TV support team seems to fix this problem. Guess this version will be released soon to public
  • mandfmike
    mandfmike Posts: 18 ✭✭

    Is this build for TV11, TV12 or ALL versions? I'm not paying for TV12 when TV11 does all I need it to do.

  • chrullrich
    chrullrich Posts: 14 ✭✭

    I have written a workaround that works for me. If any of you are desperate enough to consider using it, you can find it at [link removed]

    However, I seriously recommend that you do not use it, because you have no reason whatsoever to trust me with administrative access to your firewall policy, which is what it needs.

  • Wiedholz
    Wiedholz Posts: 5 ✭✭

    TeamViewer scheint an einer Lösung zu arbeiten, heute Morgen habe ich eine Mail erhalten, dass hier in diesem Thread ein neuer Beitrag von WouterGlas geschrieben wurde.
    Warum dieser Beitrag vom Support wieder entfernt wurde kann ich nicht sagen, er enthielt aber bereits 2 EXE-Dateien, die lt. Angabe von User WouterGlas funktionieren würden.

    MSI Dateien so schrieb er, würden im nächsten Release von nachgereicht werden.

    Inzwischen funktioniert der Download der EXE-Dateien nicht mehr mit dem Hinweis, dass der Support diese entfernt hat.
    Meine Tests mit der Host-Version dieser Dateien war aber auch erfolgreich!

    Es gibt mir etwas Hoffnung zu wissen, das der Support zumindest an dem Thema arbeitet. Auch wenn ich mir wünschen würde, dass sie uns besser über den aktuellen Stand informieren.

    ________________________

    TeamViewer seems to find a solution to work this morning, I have received an email that here in this thread a new post was written by WouterGlas.
    Why this post has been removed by the support I can not say it contained but already 2 .exe files, that would work according to the specification of user WouterGlas.

    MSI files so he wrote would in the next release of be submitted.

    Meanwhile download of the .exe files no longer works by pointing out that the support has removed these.
    My tests with the host version of these files was also successful.

    It gives me something to know hope that the support is working at least on the subject. Even though I would wish that they better inform us about the current status.

  • Julia
    Julia Posts: 290 Staff member 🤠

    Hi all,

    Thank you for your contribution here.

    Yes, it is true that we found a solution for the problem - we gave a CustomBuild to a few customers to test it and it seems like we finally found a fix for the problem.

    However, we cannot publish this version at the moment since it is a CustomBuild and not an official TeamViewer release. I will inform you, when we published an official version.

    A big THANK YOU to everyone here who helped us with giving system information or testing different things Maurice asked for.

    And of course a big THANK YOU to @Maurice our developer who fixed this.

    Cheers

    Julia
    Senior Support Engineer - 2nd level Support
    Did my reply answer your question? Accept it as a solution to help others.
    Find this helpful? Say thanks by clicking on the Thumbs Up button.
  • Julia
    Julia Posts: 290 Staff member 🤠

    Hi again,

    We've discussed this topic again internally and have come to the conclusion that we want to share with everyone the Custom Build that contains the fix.

    Here you can find the links (version 12) for the Host module and the full version:


    Host module
    Full version


    We do NOT guarantee that this version is without any bugs – as I said in my previous post, this is not an official release. There could potentially still be other bugs included – it’s up to you if you want to install this version or not.


    Cheers

    Julia
    Senior Support Engineer - 2nd level Support
    Did my reply answer your question? Accept it as a solution to help others.
    Find this helpful? Say thanks by clicking on the Thumbs Up button.
  • mandfmike
    mandfmike Posts: 18 ✭✭

    Will they be coming out with a fix for a version 11?

  • Wiedholz
    Wiedholz Posts: 5 ✭✭

    Hallo Julia,

    gibt es schon Informationen wann eine MSI Datei verfügbar ist? Für das Ausrollen per GPO. Die Host-Version läuft auf einer Testmaschine bisher ohne Probleme.

    Darf man erfahren wodurch das Problem entstanden ist und wie Eure Entwicklung es lösen konnte?

    __________________

    There is already information when an MSI file is available? For the roll-out via GPO. The version of the host runs on a test machine so far without problems.

    Can you tell us which the problem occurred and how your development could solve it?

  • Maurice
    Maurice Posts: 10 Staff member 🤠

    As far as I know the MSI file will be available with the next official release, or shortly after that.

    As for what the problem was, or what we fixed. The TeamViewer service tries to connect when it first starts using TCP. on port 5938. For some reason this first connection fails on some systems. This could have a couple of reasons (Firewall, network not yet ready, etc.). In theory this should not matter.After the first failed connection attempt the service tries to connect using HTTPS, and that's where the problem was. For HTTPS it's possible that there is a proxy in use and proxy settings are normally user settings. So the service checks if there is a user logged in and tries to impersonate that user. And for that check we had a bug because we didn't filter out app container users, which were introduced in Windows 8 to limit access to unneeded resources (e.g. the network). Until the Windows 10 Creators update this didn't cause any problems, but after it the TeamViewer service found such a user and impersonated it, which meant the serivce was using a user that has no access to the network device. So we fixed our check for logged in users and filtered out app container users.

    Maurice
    Software Developer
  • Bauer
    Bauer Posts: 6

    Thanks for the explanation.

    In our case, it was the firewall, blocking the way out of our network. Any unnesseccary ports are blocked (including 5938), and HTTP(S) is only allowed for authenticated users. Before the Creator's update, the Teamviewer service was still able to pass through for whatever reason, but after the update, the impersonation must have triggered the blocking mechanism, leaving the service unable to notify the TV server.

    The moment I opened up port 5983 for outgoing traffic, a test computer from inside our LAN appeared in my contact list as online.

    As I highly doubt that TV 10 will get patched (that's what we use), I have to evaluate to either keep that port open or simply allow all HTTPS traffic to TV servers (which should work as well, according to the explanation above)...

  • RussellR
    RussellR Posts: 1

    For anyone trying this, it is NOT port 5983.  I spent too long scratching my head on it.

    The correct port is TCP/5938.  (as in, your PC will talk TCP from a random-high-number port to the TeamViewer servers at destination port 5938).

    Had a coworker try inserting the firewall rule just to make sure I wasn't going screwy.  His dyslexia kicked in and he read 5938 on the above post and viola that worked instantly as described.  Double checked with TV support documents (should have done to start with) and the correct port is TCP/5938. 

  • dcdear
    dcdear Posts: 3

    Confused by this answer. 1703 doesn't run without this KB in place?

    Prerequisites

    If you are running Windows 10 Version 1511, to install this update, you must have installed cumulative update KB4016636, or a subsequently released Windows 10 cumulative update.  If you are running Windows 10 Version 1607 you must have installed cumulative update KB4015217, or a subsequently released Windows 10 cumulative update.  Note:  KB4013214 is required before Windows Update will download and install the Windows 10 Creators Update. 

  • jsme84
    jsme84 Posts: 3 ✭✭

    This issue is still happening and its causing me huge issues. Can you please advise on a fix for this? On computers running Windows creator update, when I restart the computer teamviewer does not start even if start with windows is ticked. It is a real issue for me because i rely on teamviewer to provide IT support to our users. I am 5000 miles away and have no access to these computers - the end users have no clue when it comes to IT so are enable to assist me in any way.,You have been harassing me to update to Teamviewer 12 over the last couple of months and this is the service we get? Please provide me with a solution to the issue this week or I will have no choice to seek an alternative.