Stații de lucru

OS - Windows 9166 Solutii

Reguli si plangeri 11 Solutii

OS - OS X 410 Solutii

Reguli de configurare 12 Solutii

Licentiere 18 Solutii

Securitate 182 Solutii

Copie de rezerva (Backup) 68 Solutii

Antivirus 72 Solutii

Aplicatii specifice 5297 Solutii

Hardware 291 Solutii

How to move your Android Auto taskbar to the side (or bottom)

Android Auto is quite literally the same Android that’s on your phone, but it doesn’t have the same level of customization. There are no alternate home screen launchers or icon packs. However, one thing you can do is move the taskbar—though the option is not easy to find.
The taskbar in Android Auto—the place where you see the clock, app shortcuts, assistant button, etc—can actually be in two locations. Depending on the size and aspect ratio of your vehicle’s display, you’ve either seen it at the bottom or side of the screen. It’s possible for you to choose the side, but it’s not clear in the settings.

“Quick Controls” have a sneaky second purpose

It determines more than it says

As I’ve alluded to, there’s not a simple setting labeled “Taskbar Location” that allows you to pick a side. Instead, where your taskbar sits actually depends on how Android Auto handles media playback controls.

In many vehicles, the Android Auto taskbar defaults to the bottom of the screen. That’s where it displays media controls—like play, pause, and skip—when you’re listening to music or a podcast. These media widgets are known in the settings as “Quick Controls,” and they’re only available in a horizontal layout.
Screenshot_20260829_153016_Open Headunit~2

Screenshot_20260829_152943_Open Headunit~2

Because of that constraint, toggling Quick Controls also dictates where your taskbar can go. When Quick Controls are turned on, the taskbar must be at the bottom of the screen to fit the media widgets. When you disable Quick Controls, those buttons aren’t needed, and the taskbar moves over to the side of the display closest to the driver.
So, moving the taskbar ultimately comes with the choice of features or layout. Quick Controls are genuinely handy if you like keeping Google Maps expanded to full screen, but still want access to your music or podcasts. On the flip side, if you already run your display in split-screen mode or would like to maximize vertical screen space, the side taskbar is a better position.

How to move the Android Auto taskbar

To shift the taskbar position, you’ll need to open the Settings app directly on your Android Auto display. This can’t be done from the settings on your phone. Scroll down until you see the toggle labeled “Show quick controls for apps.”

When switched on, it grounds your taskbar to the bottom of the screen with media controls attached. Switching the toggle off removes the extra widgets and slides the taskbar over to the side. It’s as simple as that.
Screenshot_20260829_152950_Open Headunit~2
Screenshot_20260829_152958_Open Headunit~2
Screenshot_20260829_153009_Open Headunit~2
Screenshot_20260829_153026_Open Headunit~2
Screenshot_20260829_153021_Open Headunit~2
Having the taskbar stacked vertically on the side puts the primary app icons closer to the steering wheel, which is easier to reach while driving. Since split-screen mode already keeps the media app on screen, I don’t feel like I lose much without the Quick Controls.
Speaking of media, there’s another option in the settings that lets you choose where the media app lives on the screen. You can decide if you want media or navigation close to the driver by going to Settings > Change layout.

Screenshot_20260829_162824_Open Headunit

Screenshot_20260829_162840_Open Headunit

Not a one-size-fits-all solution

As I said, screen size and aspect ratio play a part in this as well. For most standard displays, Quick Controls does indeed determine the taskbar position. However, for unconventional displays, it’s possible the taskbar may stay on the bottom even with Quick Controls disabled. You can toggle back and forth to see which layout suits your driving habits best.

 

[mai mult...]

Ghid de Diagnosticare și Soluționare pentru Eroarea Server Manager „Online – Data retrieval failures occurred” (Cod Eveniment 10149 / WinRM / WMI)

1. Introducere și Descrierea Erorii

În mediile de administrare bazate pe sistemele de operare Windows Server (Windows Server 2016, 2019, 2022 și 2025), consolă centralizată Server Manager utilizează protocoale de comunicare la distanță (WinRM – Windows Remote Management și WMI – Windows Management Instrumentation) pentru a colecta starea nodurilor, performanța, serviciile și jurnalele de evenimente (Event Logs).

Atunci când consola Server Manager afișează avertismentul:

Status: Online – Data retrieval failures occurred

Eroare WinRM / Event ID: 10149 (The WinRM service is not listening for WS-Management requests / WS-Management service cannot process the request)

aceasta indică întreruperea sau refuzul transportului de date inter-noduri. Deși serverul afectat este funcțional și raportat ca fiind „Online”, consola nu poate extrage blocurile de date/jurnale necesare pentru a compune o imagine completă de stocare, cluster sau roluri.

2. Cauzele Principale ale Erorii (Cod 10149 / Data Retrieval Failure)

Scenariile tehnice cele mai frecvente care declanșează această eroare includ:

  1. Depășirea Dimensiunii Pachetului de Date (MaxEnvelopeSizekb):

    • Atunci când un server face parte dintr-un cluster (WSFC / Failover Cluster, DAG Exchange, S2D / Azure Stack HCI), numărul de jurnale și obiecte interogate generează un răspuns HTTP/SOAP a cărui dimensiune depășește limita implicită WinRM de 512 KB (512000 bytes).

  2. Coruperea sau Blocarea Jurnalelor de Evenimente Diag (Kernel-IoTrace):

    • Jurnalul de sistem Microsoft-Windows-Kernel-IoTrace/Diagnostic poate deveni corupt sau prea masiv, cauzând blocaje de timp (timeouts) la interogările Server Manager.

  3. Serviciul WinRM (Windows Remote Management) Oprit sau Misconfigurat:

    • Ascultătorii (Listeners) WinRM pe portul 5985 (HTTP) sau 5986 (HTTPS) nu sunt activi sau binding-ul de rețea s-a pierdut pe IP-urile clusterului (Event ID 10149).

  4. Lipsa Drepturilor de Acces pe Jurnalele de Evenimente:

    • Contul de computer al clusterului sau contul de administrare nu deține permisiuni de citire în grupul Event Log Readers.

3. Ghid Pas cu Pas pentru Remediere

Pasul 1: Mărirea Limitei de Dimensiune a Pachetului WinRM (MaxEnvelopeSizekb)

Aceasta este cauza principală în peste 80% din cazurile de Server Manager Data Retrieval Failures pe servere în cluster sau Exchange DAG.

  1. Deschideți Windows PowerShell cu drepturi de Administrator pe serverul afectat.

  2. Executați comanda pentru a mări limita pachetului de la 512 KB la 8192 KB (sau până la 10240 KB):

    PowerShell

    Set-WSManInstance -ResourceURI winrm/config -ValueSet @{MaxEnvelopeSizekb = "8192"}

    Alternativ, din Command Prompt (cmd):

    DOS

    winrm set winrm/config @{MaxEnvelopeSizekb="8192"}

  3. Alternativ, prin intermediul Registry Editor (regedit):

    • Navigați la: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client

    • Creați sau modificați valoarea DWORD (32-bit) cu numele maxEnvelopeSize.

    • Setați valoarea în Hexazecimal la 2000 (corespunzător valorii 8192 în Zecimal).

  4. Reporniți serviciul WinRM:

    PowerShell

    Restart-Service WinRM

Pasul 2: Dezactivarea și Curățarea Jurnalului Corupt Kernel-IoTrace

În nodurile de Failover Clustering / S2D, jurnalul Kernel-IoTrace este o cauză cunoscută pentru blocurile de colectare Server Manager.

  1. Rulați PowerShell ca Administrator și verificați politica de Dump a Clusterului:

    PowerShell

    (Get-Cluster).DumpPolicy

  2. Dezactivați canalul de diagnosticare corupt din Registri:

    • Navigați la cheia:

      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Kernel-IoTrace/Diagnostic

    • Modificați valoarea Enabled (REG_DWORD) la 0.

  3. Reporniți serviciul de jurnale (Windows Event Log) sau efectuați un reboot al nodului afectat.

Pasul 3: Reconfigurarea Serviciului și Ascultătorilor WinRM (Fix pentru Codul 10149)

Codul de eroare 10149 indică faptul că serviciul WinRM a oprit ascultarea pe interfețele de rețea.

  1. Verificați dacă există un ascultător WinRM activ pe porturile standard:

    PowerShell

    winrm enumerate winrm/config/listener

  2. În cazul în care nu există ascultători sau sunt marcați cu erori, reinițializați configurația WinRM:

    DOS

    winrm quickconfig -q

  3. Re-înregistrați SPN-urile (Service Principal Names) și reparati legăturile WMI/WinRM:

    DOS

    netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes
winrm r /config /service @{AllowUnencrypted="true"}

Pasul 4: Verificarea Permisiunilor de Acces la Jurnale (Event Log Readers)

Pentru medii cu Active Directory și Cluster Virtual Objects (CNO):

  1. Deschideți lusrmgr.msc (sau Active Directory Users and Computers dacă este Domain Controller).

  2. Navigați la Groups $\rightarrow$ Event Log Readers.

  3. Adăugați contul de computer al serverului/clusterului și contul cu care vă autentificați în Server Manager în acest grup.

  4. Rulați comanda de actualizare a politicilor:

    DOS

    gpupdate /force

4. Rezumat și Recomandări de Prevenție

Cauză Identificată Indicator Soluție Recomandată
Limita Pachet WinRM Depășită Răspuns SOAP > 512KB Mărire MaxEnvelopeSizekb la 8192
Er. Serviciu WinRM (10149) Listener oprit / neconfigurat winrm quickconfig + restart serviciu
Corupere Kernel-IoTrace Blocaj la interogare Cluster Dezactivare registru Kernel-IoTrace/Diagnostic
Permisiuni Restricționate Acces refuzat pe loguri Adăugare cont în Event Log Readers

Concluzie:

În majoritatea scenariilor de producție (în special pe noduri de cluster, Hyper-V sau Exchange), eroarea Server Manager Cod 10149 / Data retrieval failures se rezolvă prin mărirea dimensiunii MaxEnvelopeSizekb la 8192 și repornirea serviciului WinRM, eliminând astfel gâtul de sticlă la transportul volumelor mari de date administrative.

[mai mult...]