This error appears in the event viewer when the scheduled task "ScheduledDefrag" runs.
Cause: In most cases this is cause by the -k switch which tells the defrager to perform a slab consolidation on the selected volume. This will cause an error for slabs that are less than 8 MB, and will commonly toss an error on HyperV VM's.
Solution: remove the -k switch from the task.
- Open scheduled tasks, Microsoft, windows, defrag: "ScheduledDefrag"
- Now click properties, actions, edit [start a program]
- under add arguments(optional): remove the -k and click "ok", "ok"
That's it, your done.
This message wasn't delivered to anyone because it's too large. The limit is 10 MB. This message is
This message won't be sent because it's too large
#550 5.2.3 RESOLVER.RST.SendSizeLimit.Org; message too large for this organization ##
Adjust the limits with the following powershell commands:
Set-TransportConfig -InternalDsnMaxMessageAttachSize #MB
Set-TransportConfig -ExternalDsnMaxMessageAttachSize #MB
Set-TransportConfig -MaxReceiveSize #MB -MaxSendSize #MB
Set-Mailbox "User" -MaxSendSize #MB -MaxReceiveSize #MB
gmail.com is rejecting emails from Microsoft Exchange 2010 and Microsoft Exchange 2013 email servers for no PTR records even if you do not have any IPv6 IPs assigned to the server.
The sender does not meet basic ipv6 sending guidelines of authentication and rdns resolution of sending ip. Please review https://support.google.com/mail/answer/81126for more information.
Your message wasn't delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept email from certain senders, or another restriction may be preventing delivery.
Diagnostic information for administrators:
Generating server: EXCHANGE.a51.biz
mx.google.com #550-5.7.1 [ipv6info] The sender does not meet basic 550-5.7.1 ipv6 sending guidelines of authentication and rdns resolution of 550-5.7.1 sending ip. Please review 550 5.7.1 https://support.google.com/mail/answer/81126 for more information.
Disable certain IPv6 components yourself, follow these steps:
- Use the registry editor to edit the following path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
Verify that IPV6 is disabled with the following command: "reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents"
- Edit or create DWORD (32-bit) value "DisabledComponents".
- Default value is "0", you will need to change this to "0xffffffff"(Hexadecimal "ffffffff" or Decimal "4294967295") in order to disable all IPV6 other than local loopback.
- You may receive the following error message: "ERROR: The system was unable to find the specified registry key or value."
- If you receive this error message, the DisabledComponents registry value is not set. If the DisabledComponents value is set, it overrides the settings in the connection properties.
If you have IPv6 IP's enabled on the server verify that your PTR records are correctly setup.
Error: Exchange 2013 Failed to connect to an Exchange Server in the current site. Anyone ever run into this with exchange 2013 enterprise AD and exchange are separate servers.
I checked firewall, reinstalled .net, reset IIS, etc... really stumped on this one.
New-PSSession : [exchangeserver.domain] Connecting to remote server exchangeserver.domain failed with the following error
message : WinRM cannot process the request. The following error with errorcode 0x8009030e occurred while using
Kerberos authentication: A specified logon session does not exist. It may already have been terminated.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or
use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more
information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
+ FullyQualifiedErrorId : 1312,PSSessionOpenFailed
Exception calling "FindAll" with "0" argument(s): "Unknown error (0x80005000)"
At D:\Exchange\bin\ConnectFunctions.ps1:253 char:2
+ CategoryInfo : NotSpecified: (:) , MethodInvocationException
+ FullyQualifiedErrorId : COMException
_AutoDiscoverAndConnect : No Exchange servers are available in any Active Directory sites. You can't connect to remote
Powershell on a computer that only has the Management Tools role installed.
At D:\Exchange\bin\ConnectFunctions.ps1:45 char:4
+ _AutoDiscoverAndConnect $credential $Forest -useWIA:$useWIA -ClientApplicatio ...
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_AutoDiscoverAndConnect
Failed to connect to an Exchange server in the current site.
Enter the server FQDN where you want to connect.:
Error: System.Security.Policy.PolicyException: Required permissions cannot be acquired.
This error can be caused by one of the following:
- Security permissions.
- IIS AppPool Settings, for example enable 32bit mode or load user profile may need to be set to true.