KK20

we got a cloudkey to get rid of the java service, was quite cheap.

if you want a simply batch file for opendjk11 then this should do. @echo off if exist "%PROGRAMFILES%\jdk-11.0.1\bin" goto ENDOF REM copy copy copy xcopy \\\openJDK\jdk-11.0.1 "%PROGRAMFILES%\jdk-11.0.1" /h /r /y /e /i REM now add to the path echo %path%|find /i "%C:\Program Files\jdk-11.0.1\bin%">nul || set path=%path%;%C:\Program Files\jdk-11.0.1\bin% :ENDOF

We too are experiencing a spate of disappearing printers. In a room of 30 people half may get (random PCs, random people not always the same), other half may not - some days it all may work. All PCs are equal and they all use the same GPO. I have tried both preferences (log in times drop noticeably) or I have tried good old .vbs scripts (much faster login). In either case the printers may or may not appear. In all cases if the user double clicks the VBS then the printers ALWAYS appear - that is my current fix, there are shortcuts to the VBS script that maps printers to OUs. Printers are all "user" policies as staff get slightly different options. we now have a trial in one room for "deploying" printer via the print server GPO deploy method. too early to see if this is working. obviously usual event viewer fault finding etc. 1604 was much better for us (happened "occasionally") whereas 1709 was very noticeable. We have a few 1803 test machines but they arent a reliable indicator as they arent used as much.

when we feature upgraded to 1709 (via WSUS) the test machines put everything back (we were on 1604 at the time). We took this opportunity to leave the store (and lock it down with GPOs) but carried on removing other provisioned apps we werent ever going to use. we leveraged the Users\Default\AppData\Local\Microsoft\Windows\WSUS\setupconfig.ini following the feature update to kick start our removal PS script (and also run snappydriverorigin on a few problematic laptops that had weird drivers). we are still on 1709 now and will probably move to either 1809 (if it is ever fixed) or whatever abomination arrives in april.

VLSC is the portal you log into in order to manage your volume licensing agreements, download ISO's for your licensed products, get your license keys (MAK and KMS) and assign any online agreements or benefits to other accounts (such as assigning office 365 to various tenants). Basically if you have volume license agreements then you use VLSC to manage them.

Just a note to the above. Setting the USERDATA folder needs a location that cannot be simultaneously editted if you are logging onto multiple locations (so dont use a network folder or redirected documents), it is also sensitve to versions i.e. if you open a "newer" profile on older chrome (say if a PC hasnt updated for whatever reason) then expect the userdata to bork. Using the ROAMING PROFILE seems to only take effect the during logging in and the file does not seem to lock (so can be stored in redirected documents). Older versions do not seem to bork the roaming profile. Im guessing that the roaming option simply merges the data with "whatever" is already available (if anything). Obviously "last person loggin out" will write to the file. ${documents} didnt seem to like our "redirected" documents. I used the full path with ${user_name} instead - this worked.

if the isams is locally hosted then you can script SQL to do what you want. If it isnt then you will need to shell out for isams API. The API cannot have SQL attached to it, you simply make an API, choose what access and there you go, it would be up to your "endpoint" to sanitise. as far as I am aware, groupcall xporter is just a broker, it moves data from one place to another - I dont think you can "query" the data, however I could be wrong as ive never worked with creating calls to groupcall, ive only ever installed it as part of other applications. Isams API can create standard REST API calls, you can script this in a scheduled task if you want to create CSVs etc However, at about £600 per year, the API isnt cheap and if you only use it for this job then it is an expensive proposition. You can export CSVs from isams directly (export pupil details) with a few click, you can then mangle these in excel for a single job. Come what may you will need to sanitise the data externally anyway.

if the isams is locally hosted then you can script SQL to do what you want. If it isnt then you will need to shell out for isams API. The API cannot have SQL attached to it, you simply make an API, choose what access and there you go, it would be up to your "endpoint" to sanitise. Isams API can create standard REST API calls, you can script this in a scheduled task if you want to create CSVs etc

Website (which also updates a mobile app with alert and emails staff) Text Facebook & Twitter

Old post, same issue. 10.5 installed, all the "fixes" I could find. I popped this line into the header section and now ipads, phones, small screens display correctly.

we are on 1709 all round but have left a couple of laptops out of the WSUS 1709 update group as we were curious as to what would actually happen to the 1607's

It uses IIS and SSL; No different from sharepoint or OWA. It only uses 1 factor authentication though.

my concerns were minuted. The compliance officer said "do this", they are SMT, I did it. Box ticked, concern noted. With regards to phones, it is hard enough to get phone security in any shape. However, in order for staff to use our WIFI they need to install the school cert. In order to add a private cert you need authentication. That got around half of the problem at least.

i swear to god it was at the top of the list! No idea how that happened. (shame on me. the shame). edit: i know what must have happened. This will have been a link at the bottom of another thread. apologies. I'm going to hide in the server room all afternoon to avoid being an idiot.

VPN. Staff inset training on using the VPN and not using USB pens (GDPR tick-in-box). Laptops also have bitlocker enabled (TPM) (GDPR tick-in-the-box), the weakpoint will always be the staff password. Mandatory password changes have also been implemented (GDPR tick-in-box). I love GDPR, no really, if our department wasnt vilified enough to begin with, it is now.

I use intercept X. I also have setup cryptocanary. I fail to see the downside of the screening cryptocanary approach. I run interceptX because im paranoid about the little monsters doing things I havent thought of.

dont forget that as soon as you use the hyper-v host for anything other than hosting VMs then you might need additional licensing depending on how many VMs you have running. setting the physical host as a DC definitely counts as adding another role. As for your hosts as standalones, it is a good idea to keep them as simple and stupid as possible. Their job is to keep VMs running, not worrying about other things. Backup software is a possible exception (the management of backup software should live elsewhere). Sure if your hosts cant contact the DC then they COULD log in locally. But what are you gaining by having them on the domain in the first place?

if it was clustered then you use "cluster aware updating" which doesnt do any shutting down of the guests during the node updates - it simply moves them about as necessary.

I used backupassist on two occasions to restore a physical and a VM from "bare metal" (if there is sucha thing with VM!). You use the recovery media created with BA. BA might use windows imaging as the engine but it also has its own cataloging system hence its own restore media. If you get totally stuck with drivers, simply copy the recovery info from storage to a big USB drive - this is what I did with the physical server as the BA recovery media could not see the iSCSI CSV backup directory (for obvious reasons).

if your clients can get a DHCP (im assuming you can release renew) then "something" is getting through your APs which means authentication should in theory be fine. That puts it down to possible routing (the APs themselves might have DHCP and DNS helpers so they wont need to know about routes). Look at the route table on each laptop and see if they have the correct routes (is something putting another route in there depsite the correct gateway?). Then go step by step. See if you can get to the gateway from the client, if you can then look at the gateway and ensure it can both go forwards and backwards. If that works then look at the greater network and see if THEY can go backwards. .252 is not a "common default" and might have something mis-set to .255 somewhere. Sometimes this will be good enough for DHCP and DNS (with helpers installed) but not for traffic.

x years ago when I moved my physical to virtual (2008R2 era) I did the same as you, windows backup and windows restore. the drive sizes for the VMs were IDENTICAL in size (to the Mb) as the physical. It worked a charm. Exchange and SQL server moved across but I demoted the DC first before backing up and restoring (then promoted) - I did not restore a "live" DC. I encountered no errors in the process. Windows backup (at least in the 2008R2 era) was bare metal aware. As long as the storage drivers were recognised (and as a VM it was) then it should restore.

2016 is more expensive to licence for most poeple who have modern CPU. Older servers with 16 cores total should (in theory) be the same price. If you are moving to multiple servers and intend on making a cluster, rememeber than you need to licence each server for the potential maxium VMs that could run. scenario. You have a 2cpu 8 core per cpu server. you have 8 VMS. The host server does not have additional roles other than required to run the VMs (I believe backup software is allowed as long as it is for backing up the VMs). You will need 16 core licences x8 -128 core licences to correctly licence the server. But each 2016 std licence covers you for 2xVMs so the count drops to 64core licences needed. so you will need 64 core worth of server std 2016 licences (sold in 2 or 16 packs). (source - Table Page 9 - Introduction to Per Core Licensing and Basic Definitions, April 2017 - microsoft) scenario. You have a 2cpu 10 core per cpu server. you have 8 VMS. The host server does not have additional roles other than required to run the VMs (I believe backup software is allowed as long as it is for backing up the VMs). You will need 20 core licences x8 -160 core licences to correctly licence the server. But each 2016 std licence covers you for 2xVMs so the count drops to 80 core licences needed. so you will need 80 core worth of server std 2016 licences (sold in 2 or 16 packs). (source - Table Page 9 - Introduction to Per Core Licensing and Basic Definitions, April 2017 - microsoft) If you have a 2 node cluster using the TWO servers above, you would need 144 core worth equivalent in total: 80 cores for 8VMs on one server and 64 cores for 8VMs on the other. Cores can also come in 2 or 16 packs. Spreadsheet ahoy on working those out. I dont have the prices so im not sure on how much things cost. The PDF on microsoft licensing says that the prices for 8x2core and 1x16 core is the same. P26 of Microsoft Commercial Licensing reference guide for Windows Server 2016 state that 4x2pack 2016 is the same price as 1xserver 2012R2 licence. Your mileage may vary of course.... Datacenter edition on a 16 core server would remain the same cost (in theory). I think the break even point is now 13 VMs not 10 based on a 16 core server. Unlike 2012R2 datacenter also comes with features not found on server 2012R2 such as stretch cluster with storage direct. This may be something smaller entities could leverage as it brings into reach true redundancy spread between multiple buildings based on "cheapish" storage. It is also allegedly more reliable than the old hyper-v cold replica (however that is another story).

problem solved. When I created the R610 I used the same downloads I had used for the R620 (the ISOs said they supported both hence me not worrying). Rather than look at downloading NEW drivers and having a mismatch I thought I would use IDENTICAL drivers for compatibility. This was the wrong thing to do it seems. I downloaded the latest MDSS for the MD3220 and upgraded the current MDSS on the new node only. this appears to have added different MPIO drivers to the new node system as I can now access CSVs on the new node with *any* owner on the CSV - this also appears to have fixed my non-dell iSCSI CSV too! This was most weird, I can only think that somehow the MPIO driver for the MD3220 was interferring somehow with the node CSVs - I thought the owner of the CSV should be updating metadata only (it wasnt a major role as far as im aware). I am also at a loss how the dell MPIO could affect the microsoft DSM iSCSI MPIO.... I should also point out that it PASSED cluster validation before joining (i forgot to mention that part - and as far as im aware, the cluster validation RUNS a failover on the VMs; the cluster validation could well swap the disk owner to the node it is failing over to - thus masking this particular issue!)

I didnt change the witness disk quorum settings (the quorum is actually hosted on the MD3220 HBA) and I dont seem to be able to change the owner of the quorum (which makes sense as it isnt a CSV - it is listed as a witness quorum disk, the cluster sorted the disk quorum out when it was created). I havent touched any permissions to any folders on the CSV folders, i'll monitor the raw permissions when i change owners manually. Im just creating a fresh volume and LUN on the MD3220 from some free space. Id rather not mess about with live CSVs so ive taken affinity off the VMs for the new node and will play about with the "test" voume im creating. Looking in MD3220, it sees the new node as a valid host, the host is in the correct storage host group with the LUNs (4 total LUNs plus a quorum LUN), it sees both HBA paths - all looks the same as the other nodes in the cluster. The iSCSI (synology) array is quite simplistic, it shows 3 targets active and the single LUN is set to read/write (it does not seem to have the ability to set read only per target, only for the LUN as a whole). once the new lun/storage has been added to the cluster I will play with that CSV and monitor the permissions depending on owner etc. That might shed some light. edit: the windows updates are the same on each server - I made sure I ran a cluster aware update before I added the new node. The new node was updated before being added too.

I didnt change anything on the iSCSI host box, i merely added the new node iSCSI target on the node, added the CHAP credentials the discovered the LUNs, then joined the cluster. All appeared fine (the target node appears in the iSCSI host screen the same as the "old" nodes). The odd thing is, the primary SAN is HBA, the backup is iSCSI and CSVs that are located on either are affected - if the CSV isnt owned by the new node then the new node cannot write to that CSV (regardless if it is a HBA or iSCSI "hosted" CSV). The old nodes dont care who owns the CSV - they can read write at any time. I'm thinking an evict and reinstall from scratch in case ive missed some driver or whatnot; I could understand if I had forgotten (say) a HBA driver but for iSCSI *and* HBA hosted CSVs to be affected had me stumped.