MSA : Inbound Errors

HP MSA 2040 

Now according to here : MTU is 8872 ( 8900 ) no 8972 ( 9000 )

Make sure this is enabled on the SAN

Extreme Summit Switch x460 Jumbo Frames

#enable jump frames on all ports

enable jumbo-frame ports all

#list all ports in use to get port numbers

show port utilization

#check MTU of each port to make sure Jumbo:  Enabled, MTU= 9216

show port <#> info detail

Server 2012 R2 Core Hyper v

OK we have an iSCSI Adapter on the server called iSCSI1, the below should come up with a reply if working

ping <IP OF iSCSI SAN> -f -l 8972 

If not lets recheck all settings : First lets get the Make of the adapter :


We want to list all the properties for network card

Get-NetAdapterAdvancedProperty -Name iSCSI1

Check the JumboPacket is 9014 and is enabled

Set-NetAdapterAdvancedProperty -Name “ISCSI” -RegistryKeyword “*JumboPacket” -Registryvalue 9014

Lets also set via Netsh, first lets list current MTU :

netsh interface ipv4 show interface

Lets change adapter

netsh interface ipv4 set subinterface “iSCSI1” mtu=8900 store=persistent
VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Recently we had an issue where a Office 365 Hybrid Environment where a local user would reset their expired Local Password and the ADDconnect service would disconnect the user and delete the Mailbox and User account. We could restore the Mailbox from deleted Users in the Admin Panel however it was only restoring “In Cloud” rather than “Synced with Active Directory”

I checked the ImmutableId for the User in 365

Get-MSOLUser -UserPrincipalName |flGet-ADUser -Filter {UserPrincipalName -like } -Properties ObjectGUID | select ObjectGUID

which is the unique value AADconnect uses to sync between on-premise and 365 and it was the same.

Running through the ADDconnect “Customize Synchronisation Options” showed the AD group created for selective Users to be Synced had been moved to a different OU and it could not reference this anymore.

Fixing the OU location of the Group resolving this fixed the accounts back to 


VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Recently I tried to boot an hp elite 8200 Compaq desktop from USB, however, pressing the f9 key on bootup was not showing me any USB key. 

Upgrading the BIOS did not fix the issue

I have to Reset the BIOS to factory defaults which then showed the USB Key

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Previously, we used a development instance of Azure AD Connect with a development Azure AD tenant to investigate the rules. However, Microsoft has created new functionality in the ADFSHelp Portal:

The ADFSHelp Portal in Microsoft Edge (click for larger screenshot)

ADFSHelp ToolsIn the Tools section, there is now a Claims Generator wizard labeled Azure AD RPT Claim Rules, that will help you get optimized claims rules for the ‘Office 365 Identity Platform’ RPT.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

This can be used to install the N-able agent on Startup or through something like PSEXEC with Batch Patch . this only supports Agents137 and below

@echo off


REM WindowsAgentSetup.exe can be downloaded from N-able by Manual Add Device

xcopy /y /e \\%pathtonableinstaller%\137WindowsAgentSetup.exe c:\Temp\137WindowsAgentSetup.exe*

title Installing N-able Remote Monitoring Software

SET	"server=%nableserverAddress%"

REM Can be found by going to the root of your N-able , Administration Tab on the Left then Customer


SET	"installerLocation=c:\Temp"

SET	"alreadyInstalled=The N-able Agent is already installed"

SET	"notInstalled=The N-able Agent is not yet installed, installing it now..."

SET	"programFiles=c:\program files"

REM       Check to see if its x86 or x64

IF %PROCESSOR_ARCHITECTURE% EQU  AMD64 ( SET "programFiles=%programFiles% (x86)" )

REM Debug Information

echo %server%

echo %customerID%

echo %installerLocation%

echo %programFiles%

IF NOT EXIST "%programFiles%\N-Able Technologies\Windows Agent\bin\agent.exe" ( GOTO INSTALL ) else ( GOTO AlreadyInstalled )



echo %notInstalled%

%installerLocation%\137WindowsAgentSetup.exe /s /v" /qn CUSTOMERID=%customerID% CUSTOMERSPECIFIC=1 SERVERPROTOCOL=HTTPS SERVERADDRESS=%server% SERVERPORT=443"



echo %AlreadyInstalled%



If installing via Batch Patch use the Software Deploy to run the .bat


The best way I have deploying anything higher then Nable Agent 137 , is run the .exe and go to %temp% and get the WindowsAgent.msi and deploy with 

msiexec /i “\\pathj\WindowsAgent.msi” /q CUSTOMERID=”%number%” CUSTOMERSPECIFIC=”1″ SERVERPROTOCOL=”HTTPS” SERVERADDRESS=”%server%” SERVERPORT=”443″

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

The event log shows the below error : 

Faulting application name: WINPROJ.EXE, version: 16.0.9126.2072, time stamp: 0x5aa71b2d Faulting module name: mso20win32client.dll, version:, time stamp: 0x5aa6e4e7 Exception code: 0x010d5840 Fault offset: 0x00152808 Faulting process ID: 0x18b4 Faulting application start time: 0x01d3bffa8580d681 Faulting application path: C:\Program Files (x86)\Microsoft Office\root\Office16\WINPROJ.EXE Faulting module path: C:\Program Files (x86)\Common Files\Microsoft Shared\Office16\mso20win32client.dll Report ID: 15fb1e4a-ee75-4217-9a89-1e75433a8b0a Faulting package full name: Faulting package-relative application ID:

Resetting the Registry and User App data for MS project does not resolve this 

You will have to go into Control Panel and do an Online Repair ( quick repair does not fix this ) 

VN:F [1.9.22_1171]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)

The first delay is a long cycle of checking every file mentioned in the VSS writers metadata. There are 8 million of FILESTREAM blobs on that server. This must be what causes this cycle to be so long for that volume.


Please download the bundle here:

To install, do the following on Veeam server and any Guest Interaction proxies that you have:
1. Locate C:\Program Files (x86)\Veeam\Backup Transport\GuestInteraction\VSS\VeeamGuestHelpers
2. Rename VeeamVssSupport2003_X86.dll to VeeamVssSupport2003_X86.dll_old
3. Rename VeeamVssSupport2008R2_X64.dll to VeeamVssSupport2008R2_X64.dll_old
4. Rename VeeamVssSupportXP_X86.dll to VeeamVssSupportXP_X86.dll_old
5. Extract new versions of these 3 DLL files from the archive.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)