If you are trying to get the size of your Synology Volume via SNMP < you will need to query the correct Index on the OID .1.3.6.1.2.1.25.2.3.1.3.

Synology does not have standard indexes , so you will need to start by downloading run and install SNMP walk on a machine that can communicate to the device over network

Enter the IP of the device in SNMP Walk ( Leave rest options to default ) and get the output to text File

Open the txt file and do a Search for volume and per below you should fine the list of OID’s

The last number will be the index , for example Index will be 41 fo the volume

.1.3.6.1.2.1.25.2.3.1.3.1 = STRING: “Physical memory”
.1.3.6.1.2.1.25.2.3.1.3.3 = STRING: “Virtual memory”
.1.3.6.1.2.1.25.2.3.1.3.6 = STRING: “Memory buffers”
.1.3.6.1.2.1.25.2.3.1.3.7 = STRING: “Cached memory”
.1.3.6.1.2.1.25.2.3.1.3.8 = STRING: “Shared memory”
.1.3.6.1.2.1.25.2.3.1.3.10 = STRING: “Swap space”
.1.3.6.1.2.1.25.2.3.1.3.31 = STRING: “/”
.1.3.6.1.2.1.25.2.3.1.3.36 = STRING: “/tmp”
.1.3.6.1.2.1.25.2.3.1.3.37 = STRING: “/run”
.1.3.6.1.2.1.25.2.3.1.3.38 = STRING: “/dev/shm”
.1.3.6.1.2.1.25.2.3.1.3.41 = STRING: “/volume1”

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 , users where getting the below error from a Web App they use

This is due to the mixed code security which needs to be set to : “Enable – hide warning and run with protections”

To deploy this setting to all computers on a network via Group Policy follow the guide below , here is the Java Reference

Create a GP to delpoy the following file to C:\Windows\Sun\Java\Deployment\deployment.config

deployment.system.config.mandatory=true
deployment.system.config=file:///C:/WINDOWS/Sun/Java/Deployment/deployment.properties

Create a GP to delpoy the following file to C:\Windows\Sun\Java\Deployment\deployment.properties

# Mixed code (sandbox vs. trusted) security verification
deployment.security.mixcode=HIDE_RUN
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 had a few Zerto Recovery Groups ( VPG’s ) came up with the state 

Recovery is possible. (0%)

Connecivity to the VM’s where ok , and when I ran through the Wizard after Editing the VPG is came back with all ticks. A reboot of the server and SCVMM server did not clear the issue either

In the end we had to perform a “Force Sync” to resync the delta’s

 

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 was trying to get a WDS server PXE Booting using Legacy and UEFI booting. I followed the DHCP guide here Legacy worked however UEFI was not working. I double checked on the WDS server for the 67 Option with a file share and in

\\%IPOFSERVER%\reminst\Boot\x64

wdsnbp.com existed but no wdsmgfw.efi

Running a rebuild of the boot files also did not fix this for some reason , in the end I copied the file from : 

\\%IPOFSERVER%\c$\Windows\System32\RemInst\boot\x64

and it resolved the issue

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

How to get the OneDrive .ADMX files for Group Policies

On a machine with the latest of One Drive for Business installed, navigate to : %localappdata%\Microsoft\OneDrive

Find the latest version number in the folder and open it then go to the adm folder and copy the  .admx file

to \\domain.local\SYSVOL\domain.local\Policies\PolicyDefinitions and .adml file to \\domain.local\SYSVOL\domain.local\Policies\PolicyDefinitions\en-us\

Set Policies

Configure your Group Policies to the settings you want, but the one you’ll need for auto sign in is “Silently configure OneDrive using Windows 10 or domain credentials“. ) This will set : [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\OneDrive] “SilentAccountConfig”=dword:00000001. 

and also it will set Modern Authentication: 

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive] “EnableADAL”=dword:00000001 

 

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

So you’ve found an issue in a Package in a Project for a DataSynchronization in a Integration Services Catalogs ( .dtsx file ) that you want to edit?

Install if its not already on it and open SQL Server Data Tools

Click on File and New Project

Choose this Project

Choose “Intergration Servies Catalog” and Open the project

You should see the .dstx files on the right under

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

You will probably be given the files in a Zip file something like

SV9100_UC_Suite_AU_v4.5.4_R2

Extract this zip file

Download and install 7zip then extract UC_InConnect-4_5_4.exe to a folder UC_InConnect-4_5_4

You will now see the MSI file to install 

UcConnector.msi

Move this file to a share on a server ( or DFS location if you have multiple sites ) and make sure Domain Computers has read Access to the Share and the security on the folder

Create a new Group Policy and add it to the Policy Assigned Apps

How apply this policy to the Workstations OU

And on reboot you should see the below on the desktop

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)
Faulting application name: OUTLOOK.EXE, version: 16.0.10325.20118, time stamp: 0x5b6376e5
Faulting module name: OUTLOOK.EXE, version: 16.0.10325.20118, time stamp: 0x5b6376e5
Exception code: 0xc0000005
Fault offset: 0x000000000033246b
Faulting process id: 0x36c4
Faulting application start time: 0x01d43f25ac04f67c
Faulting application path: C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE
Faulting module path: C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE
Report Id: 9833d931-82c0-4400-8f12-18a00e63fdb1
Faulting package full name:
Faulting package-relative application ID:

 

Outlook 2016 was crashing when changing folders. The event log brought the above error. Rebuilding the OST did not work, in the end we had to uninstall and reinstall Office

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

When they initially onboarded, there was no filtering or security in any form:

Running a simple audit against Azure AD>Sign-ins showed the extent, even more when you export a CSV.

2000+ failed attempts within 24 hours:

Step 1) Sort or filter the CSV to find common trends (specific user account/IP/Country:

In this case, the client doesn’t have staff in China, nor should anyone be accessing from there

Step 2) Create a Blacklist – AzureAD>Conditional Access.

  • Create a Named location – in this case I named it ‘Blacklist’

 

 

  • Add any IPs to the blacklist

 

  • Create a policy – Name accordingly

 

  • Filter by a test account if appropriate, same for specific apps (don’t filter all apps if the admin account is included!! This can lock you out of the portal if you make a mistake!)

  • Set the blacklist location

  • Block the blacklist (or if you’re creating a whitelist, just allow instead of reject)

  • Enable the policy, then click the ‘What If’ button and test

 

 

Make sure it works as intended!

 

 

End result:

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