Run As Administrator not always working?
I have dealt with this for about 10 years now since Server 2003/Windows XP. Just now getting around to addressing this. If this isn't the right place, I'd appreciate a link to the right place. Have a Server 2019 domain with 13 workstations all running Windows 11 Pro. Workstation user only have user access rights. On occasion I'll need to run something, such as services.msc for example with admin rights. On some workstations I can right-click services, select Run As Administrator, enter the domain admin credentials and can then stop/start/change services as needed. Yet on other workstations the Run As Administrator doesn't work. It runs services.msc. But I'm not prompted for admin credentials and can't start/stop/change the service. What can I do to make it work so I don't have to waste time logging of the normal user to log in with a domain admin account? Note that I do have and use group policies on the server. I've never "knowingly" set any policy that would prevent the Run As Administrator for working. I also have WSUS set up and it's configured with SSL if that matters. Thanks for any feedback on this. - Carl
New Teams / Meeting addin missing on Windows Server 2019 RDSH / Autostart Issue
Dear Community, dear Microsoft Pros, We are currently struggling with getting the New Teams running smoothly on our RDSHs. It was already a painful experience to remove the old Teams and install the New Teams there. But now the addins are missing completely - the presence addin everywhere (also on the Win10/11 clients, but this is another story), and the meeting addin on the RDSHs. We managed to find out, the addin installer is embedded as an MSI in the original New Teams installer and resides in the WindowsApps folder. We think, this installer will run in user context, so this is trouble because the users are not allowed to install MSI. Ultimately, we can only achieve a complete installation including the plugin on an administrator account. All normal users will not get the plugin installed. Also, the new teams is still struggling to update on several user accounts and starting on user logon. I guess this needs to be fixed by Microsoft - especially in the light of the fact that the classic teams will be shut down at the end of the month. Meanwhile I'm looking for workarounds to get the addin running, because our colleagues rely on it. Our Setup: Windows Server 2019 Datacenter Edition, Microsoft 365 Classic Teams removed New Teams installed via Dism /Online /Add-ProvisionedAppxPackage /PackagePath:"MSTeams-x64.msix" /SkipLicenseServer 2019 Domain Controllers: lsass.exe terminated unexpectedly with status code -1073741819
Basically my issue matches https://learn.microsoft.com/en-us/answers/questions/612097/windwos-2019-lsass-exe-terminated-unexpectedly-wit?source=docs exactly. We have Server 2019 DCs running on VMware vSphere 7.0 U3c. The non-PDC DCs are randomly rebooting with the below event log message: EventID : 1074 MachineName : DC19** Data : {} Index : 544467 Category : (0) EntryType : Information Message : The process wininit.exe has initiated the restart of computer DC19RP on behalf of user for the following reason: No title for this reason could be found Reason Code: 0x50006 Shutdown Type: restart Comment: The system process 'C:\Windows\system32\lsass.exe' terminated unexpectedly with status code -1073741819. The system will now shut down and restart. Source : User32 ReplacementStrings : {wininit.exe, DC19**, No title for this reason could be found, 0x50006...} InstanceId : 2147484722 TimeGenerated : 4/23/2023 5:07:58 AM TimeWritten : 4/23/2023 5:07:58 AM UserName : NT AUTHORITY\SYSTEM The servers are all patched to the current CU - 2023-04 (KB5025229), so they should all have the most recent KB I've found that addresses lsass.exe crashes (KB5010791) installed. I've also noticed that shortly before the lsass.exe crash, there will be an event log similar to the one below, although each references a different WMI filter: EventID : 1065 MachineName : DC19** Data : {} Index : 544466 Category : (0) CategoryNumber : 0 EntryType : Error Message : The processing of Group Policy failed. Windows could not evaluate the Windows Management Instrumentation (WMI) filter for the Group Policy object cn={***},cn=policies,cn=system,DC=fabrikam,DC=com. This could be caused by RSOP being disabled or Windows Management Instrumentation (WMI) service being disabled, stopped, or other WMI errors. Make sure the WMI service is started and the startup type is set to automatic. New Group Policy objects or settings will not process until this event has been resolved. Source : Microsoft-Windows-GroupPolicy ReplacementStrings : {4, 714, 0, 136750...} InstanceId : 1065 TimeGenerated : 4/23/2023 5:07:58 AM TimeWritten : 4/23/2023 5:07:58 AM UserName : NT AUTHORITY\SYSTEM Once the server is back up and running after the reboot crash, WMI appears to be working fine, and I'm not seeing any other errors specifically referencing WMI itself in the period leading up to the crash.
Unattend accept eula doesn't work in server 2019
Quick background history of the image. My colleague created an image for openstack instances with windows server standard 2019. My task was to create it for baremetal servers. I took the vhdx file (because has many customization inside with applications) , inject the drivers for hp gen10 servers, convert it to wim and used it. I syspreped the image when I finished with it with the generalize and oobe and shutdown command then I wanted to use the wim file for further baremetal deployment. Our deployment is a bit complex, but you can see the structure in the unattend file. The main thing the automation tool took the customized wim file and put the unattend file in the c:\, in the panther directory, in the sysprep directory and in the panther/unattend directory. I spent 3 days already on to figure out wher eis the problem but I can't, I think the problem is somewhere in the logic in the unattend of I have no clue at all 😞 So the f...ng screen that always come up is this: This win2012r2 one come up at the boot as well, but I don't think it is a problem, we might use some customized efi thing, but it doesn't disturb anything, just let you know maybe you think different. https://pastebin.com/5rHfTJNv is the unattend file. (I removed the product key (MAK key) and renamed the company). And this is the logs on the newly installed servers in the unattend panther directories. https://pastebin.com/raw/u4R9RYXD https://pastebin.com/raw/CK12jZc3 If this 1 accept eula wouldn't come up, everything would be perfect, but with this it completely break the maas deployment 😞 The windows is activated inside the wim, not sure also is it a problem or not, just for your information. I hope somebody can figure out what is the issue 😞Issues with Remote Desktop access on Server 2019 Virtual Server
Hi everyone, I'm having some issues with using a terminal server that I've setup inside of Server 2019. We currently have a company with about 30-40 employees that use a VPN and remote desktop into a server that is virtually hosted (VMware) on a local server. I'm running into an issue where some employees remote in and the session freezes at either the login screen or afterwards using a program on the server. This happens almost daily, but does not affect everyone at the same time. If they exit the connection and go back in, it will work properly for a few seconds and then freeze again. It also seems to register any clicks on the server when frozen, like if I open a program it will be open the next time I reconnect. It's almost like the viewing of the screen is frozen but the session is still working properly. I find that a server reboot or a restart of the Remote Desktop service will fix this issue, usually for the full day. I've created a task that restarts the service early in the morning, but the issue sometimes still crops up. There are no errors in the event log as far as I can tell. This issue has been happening ever since I created this new server and gave it the remote desktop roles. Please let me know at least a direction I can look into, or what information is needed for more troubleshooting. Thanks in advance, Devon LaVoy Systems Administrator
SQL 2019 Fails to Start - Error 17051
I have a fairly significant set of issues that I cannot figure out how to resolve that has brought down a bunch of systems. A windows update occurred and the SQL 2019 RC1 server rebooted itself (do not believe that this error is related just coincidental). This error indicates that the SQL Server evaluation period has expired. Upon reviewing the startup logs this concurs with my belief: I am confused about why I am running into this issue as I am running a developer version of SQL and not the evaluation version but none the less it currently appears to be a problem. To attempt to resolve this issue I have done the following: Attempted to do an edition upgrade and set everything back to developer and the process ran and completed successfully but the service will still not start. Attempted to upgrade editions to a licensed version of SQL (which I do also own) and I cannot complete the upgrade because the SQL server is not running. I attempted to follow instructions to turn back the computer time and set common files registry entry to "3" in an attempt to trick it into being active so that I could upgrade. My system automatically reverts the time back to the standard time almost immediately. Attempted to turn off network connection to disable time sync Defaulted the time settings for windows Unjoined the server from the domain thinking GPO might be interfering This system MUST be restored. Any ideas you have on how to get it back up and running again would be seriously appreciated!Cannot Sign into Edge on Domain Controllers running Windows Server 2019 Standard
I know this is more of an Edge issue than a Server issue, but it's specific to Server 2019 Standard running as a domain controller, so I'm starting here. Edge version: 108.0.1462.76 (Official build) (64-bit) OS: Windows Server 2019 Standard (Build 17763.3770) When I launch Edge on any of my 23 Domain Controllers running Windows Server 2019, I am unable to sign into Edge with my "work or school" account (my AD/AAD credentials). I have no issues signing into Edge on Server 2019 member servers. When I first launch Edge on a member server, it automatically logs me in and gives me the below screen: However, when I launch Edge on a domain controller I get this: After clicking "Sign in to sync data", I get an MS login window: Then, upon typing in my AD/AAD credentials, I get a popup window with the below message: We can't sign you in right now The Microsoft Edge team has been notified of this issue. Please try again later. Error code: 3, 15, -2146893039 edge://signin-error/ Any suggestions?
Server 2019 ADFS LDAP Errors After Installing January 2022 Patch KB5009557
As it stands now, it appears that KB5009557 breaks 'something' with the connection between ADFS and AD. When this happens you are unable to SSO until the ADFS server is rebooted (sometimes it takes several times). We started getting errors (I'll paste the error below) after installing 5009557, and as soon as it pops up, you will get them continually until a reboot. However if/when the reboot does fix it, it will only be temporary as it seems that at some point (maybe when the kerberos ticket needs to be refreshed??) that it will break again. Right now our heavy hitter is our Sharepoint relying party so that will be shown in the error below. On one occasion ADFS did break when I rebooted a few domain controllers. We are currently using a gMSA and not a traditional service account. We have validated that other systems are able to query the domain via LDAP connections successfully with a gMSA after installing the January patches. This is only affecting the ADFS servers. The ADFS servers are still able to retrieve the gMSA password from the domain. Our domain is healthy. No replication errors or any other issues. We do not have any one-way trusts etc. So far the only thing that has worked for us is to uninstall KB5009557, which of course we don't want to do for security reasons. What hasn't worked: Updating the krbtgt password in proper sequence. Installing OOB patch KB5010791. I see that KB5009616 was released on 01/25 and it does mention a few kerberos items but the only thing related to ADFS is: "Addresses an issue that might occur when you enable https://docs.microsoft.com/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-logging and an invalid parameter is logged. As result, Event 207 is logged, which indicates that a failure to write to the audit log occurred." Which isn't our issue. Anyone know if this patch from the 25th resolves it? We're going to install it on one of our ADFS servers as a test. Below is the error seen when the connection between ADFS and AD breaks: Encountered error during federation passive request. Additional Data Protocol Name: wsfed Relying Party: urn:sharepoint:prod Exception details: Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> Microsoft.IdentityServer.ClaimsPolicy.Language.PolicyEvaluationException: POLICY0018: Query ';tokenGroups,sAMAccountName,mail,userPrincipalName;{0}' to attribute store 'Active Directory' failed: 'The supplied credential is invalid. Error code: 49 Server response message: '. ---> Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapServerUnavailableException: The supplied credential is invalid. Error code: 49 Server response message: ---> System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid. at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential) at Microsoft.IdentityServer.GenericLdap.Channel.ConnectionBaseFactory.GenerateConnection() at Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapConnectionCache.CacheEntry.CreateConnectionHelper(String server, Boolean isGC, LdapConnectionSettings settings) --- End of inner exception stack trace --- at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result) at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result) at Microsoft.IdentityServer.ClaimsPolicy.Language.AttributeLookupIssuanceStatement.OnExecuteQueryComplete(IAsyncResult ar) --- End of inner exception stack trace --- at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result) at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result) at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims) at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection) at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, SecurityToken deviceSecurityToken, String desiredTokenType, WrappedHttpListenerContext httpContext, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, MSISSession& session) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSerializedToken(MSISSignInRequestMessage wsFederationPassiveRequest, WrappedHttpListenerContext context, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken) --- End of inner exception stack trace --- at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context) at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler) at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context) Microsoft.IdentityServer.ClaimsPolicy.Language.PolicyEvaluationException: POLICY0018: Query ';tokenGroups,sAMAccountName,mail,userPrincipalName;{0}' to attribute store 'Active Directory' failed: 'The supplied credential is invalid. Error code: 49 Server response message: '. ---> Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapServerUnavailableException: The supplied credential is invalid. Error code: 49 Server response message: ---> System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid. at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential) at Microsoft.IdentityServer.GenericLdap.Channel.ConnectionBaseFactory.GenerateConnection() at Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapConnectionCache.CacheEntry.CreateConnectionHelper(String server, Boolean isGC, LdapConnectionSettings settings) --- End of inner exception stack trace --- at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result) at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result) at Microsoft.IdentityServer.ClaimsPolicy.Language.AttributeLookupIssuanceStatement.OnExecuteQueryComplete(IAsyncResult ar) --- End of inner exception stack trace --- at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result) at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result) at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims) at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection) at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, SecurityToken deviceSecurityToken, String desiredTokenType, WrappedHttpListenerContext httpContext, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, MSISSession& session) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSerializedToken(MSISSignInRequestMessage wsFederationPassiveRequest, WrappedHttpListenerContext context, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken) Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapServerUnavailableException: The supplied credential is invalid. Error code: 49 Server response message: ---> System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid. at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential) at Microsoft.IdentityServer.GenericLdap.Channel.ConnectionBaseFactory.GenerateConnection() at Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapConnectionCache.CacheEntry.CreateConnectionHelper(String server, Boolean isGC, LdapConnectionSettings settings) --- End of inner exception stack trace --- at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result) at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result) at Microsoft.IdentityServer.ClaimsPolicy.Language.AttributeLookupIssuanceStatement.OnExecuteQueryComplete(IAsyncResult ar) System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid. at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential) at Microsoft.IdentityServer.GenericLdap.Channel.ConnectionBaseFactory.GenerateConnection() at Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapConnectionCache.CacheEntry.CreateConnectionHelper(String server, Boolean isGC, LdapConnectionSettings settings)RDS 2019 HTML 5 keyboard shortcuts
Hi everyone, We have implemented HTML5 with Azure application to allow users to connect from home to our RDS servers. It works great, however a couple of issues we found: keyboard shortcuts such as ALT+TAB (ALT+PageUP) not working (Or I need to change something somewhere) When publishing remote app to user it removes the remote desktop option. Icons are not display correctly... the user sees broken image icon Sometimes when clicking on an icon it won't work and a page refresh is required which results in another login page. When changing language (using ALT+SHIFT), the RDS is not using the language configured in the session. It uses the language from the local computer. We would like to use HTML5 as it is more secure than the the RDP protocol. If there are any resolutions to what I wrote it would be amazing. Rahamim.
