Having the option to do so on client systems would be nice. I guess the decision is along the line that workstation storage is cheap
> On 4 Mar 2016, at 14:26, Michael Mott <[email protected]> wrote: > > Neither, running the de-dup command on desktop OS’s as a whole. > > From: [email protected] [mailto:[email protected]] > On Behalf Of Andreas Hammarskjöld > Sent: Friday, March 04, 2016 3:53 AM > To: [email protected] > Subject: RE: [mssms] Use of Riverbeds at remote offices > > I am confused now Mike, are you arguing against Troys list or the dedupe > list? If you are recommending a big fat .wim with all the OS flavors in them > I don’t get why Troy brought up the list in the first place? Or are you > talking about Johans 25GB images and not the 25Gb Troy list? > > Typically, our customers deploy a very low number of images. Normally, only > one version of the OS, either Enterprise or Pro. If you are also some > eligible to the Education SKU, you deploy that as well. In some rare cases > you also deploy x86 images but very rare, and typically only to EFI tablets > that can only run x86. > > Most people don’t use the .WIM capabilities of multi-image as ConfigMgr > doesn’t support creating them, and if you update one you don’t need to update > the whole thing. Also, for the technical audience, .wim’s are single instance > storage on the file level, not block level. So one single byte difference and > you get another file entry. Funnily enough, DeDupe shaves of 10% of the > transfer of a box standard .wim image just by de-dupe it on the transfer, > pretty impressive. > > //Andreas > > From: [email protected] [mailto:[email protected]] > On Behalf Of Mike Terrill > Sent: den 4 mars 2016 02:05 > To: [email protected] > Subject: RE: [mssms] Use of Riverbeds at remote offices > > This is great and all, but aren’t you assuming that there is more than one > flavor of Windows being deployed? (BTW - It is a good thing to understand > customer scenarios and needs before jumping to conclusions on what you think > they need). > > It is a different story when the WIM (which the last time I checked was > already single instanced) only contains one Windows edition. In this case, it > just happens to be a huge (super thick) WIM file. > > Before you reply, I get your points about there being multiple WIMs of > varying editions and the benefits of DeDup that you describe below. But, I > just thought it would be good to keep things relative to the scenario instead > making assumptions… > > BTW – no disrespect to either of you. Like Troy, I equally respect you guys > and your continued engagement with the systems management community. > > From: [email protected] [mailto:[email protected]] > On Behalf Of Phil Wilcock > Sent: Thursday, March 3, 2016 8:04 AM > To: [email protected] > Subject: RE: [mssms] Use of Riverbeds at remote offices > > <picks up mic> > > Troy – if you used DeDupe you’d only need to send one email mate J > > And yes, when it stops being fun, we’ll all go home! > > Looks like an interesting gig for the (other) Swede! But… > > 25Gb images X 442 = 11TB over the wire, even if, using Nomad P2P, some of > that is LAN not WAN traffic. > > Oh, if only he had access to DeDupe (Free for the customer) and BranchCache > (also Free) he would probably be sending out 5-6GB instead of 25, and be home > now having a well-earned Pint J > > See you at MMS Mr Martin! > > > > From: [email protected] [mailto:[email protected]] > On Behalf Of Troy Martin > Sent: 03 March 2016 13:43 > To: [email protected] > Subject: Re: [mssms] Use of Riverbeds at remote offices > > Andreas/Phil, > > I had much respect for you guys when we worked together at 1E, and I still do > today. You're both very intelligent and I applaud you're efforts in the > community. None of this is personal, but you're sure making it fun! > > BranchCache is good tech. However, let's see what the best use when doing > "real-world" OSD... > > > <drop the mic> > > > <image001.jpg> > Johan Arwidmark (@jarwidmark) > 3/2/16, 11:18 PM > In the POC lab, pushing 25 GB images to 442 laptops in a distributed > environment using SCCM and @1E_Global pic.twitter.com/yxuulxQs2I > > 1E | Software Lifecycle Automation > > On Mar 3, 2016, at 6:46 AM, Andreas Hammarskjöld <[email protected]> > wrote: > > I would say - if you want to educate you have to tell the whole story. Why on > earth would you push 25GB of .iso to a branch (head office shouldn’t be > included I think)? > > First off, skip the x86 builds, nobody does x86 these days? Or am I wrong? > Then, no need to download the wim’s and ISO’s? Or do you expect people to > burn their own DVD images in the branches? > > So my list of media would look like the following, education and enterprise > x64 (Included x86 for reference here): (Skipping LTSB to keep Johan A happy > ;-). > > So let’s have a look what de-duplication would do to that: > > File > DedupSize (deduped content) > Size of file > Saving (What to transfer) > Percentage > h:\en_windows_10_education_version_1511_x64\install.wim > 3088088801 > 3330923026 > 242834225 > 92,71% > h:\en_windows_10_education_version_1511_x86\install.wim > 2286524835 > 2440168556 > 153643721 > 93,70% > h:\en_windows_10_enterprise_version_1511_x64\install.wim > 3088534192 > 3330734792 > 242200600 > 92,73% > h:\en_windows_10_enterprise_version_1511_x86\install.wim > 2287174295 > 2440826179 > 153651884 > 93,70% > > Note that those stats are from de-duped storage savings. So if you were to > transfer these files using BranchCache that would roughly reduce the size by > about 46%. (You still have to get the first data down there). > > So instead of 6.6 GB for the x64 it would transfer 3+ and for the x86 4.4GB > it would transfer 2.2. Most people wouldn’t do enterprise and education > though, so typically you would only have your x64 master .wim to deploy and > not 25GB of unneeded crap. > > //Andreas > > From: [email protected] [mailto:[email protected]] > On Behalf Of Phil Wilcock > Sent: den 3 mars 2016 08:55 > To: [email protected] > Subject: RE: [mssms] Use of Riverbeds at remote offices > > Jason, I did test BranchCache in Hosted Cache mode (ages ago, and only > superficially) – and it worked with SCCM, so as Andreas said, it’s probably > more of a common sense/design constraint that led to MS not supporting that > config. > > Incidentally, I went to a session at NICCONF by Riverbed – their new SD-WAN > stuff looks interesting, and I see that they bought another SD-WAN provider - > https://www.ocedo.com/en/ recently > > As to the RiverBed publishing an SCP – don’t know but I have some PowerShell > that can do that for you if you need it…somewhere.. > > 25Gb Troy? Phew that’s a lot of content.. > > Still, with a lot of common blocks in there, DeDuplication should reduce that > by about 75-90% - all the way to the client. > > ..But only if you use BranchCache > > Cheers > > Phil > > > > From: [email protected] [mailto:[email protected]] > On Behalf Of Troy Martin > Sent: 02 March 2016 23:00 > To: [email protected] > Subject: RE: [mssms] Use of Riverbeds at remote offices > > Hey Jason, > > One consideration for managing the realities of WAN optimization devices > (i.e. Riverbed) in place of DPs, is during OS migrations and trying to keep > the large OSD content “fresh” on the devices. WAN/Riverbed devices often > come with “not enough” disk space when it comes to hosting OSD content and > other business content simultaneously i.e. Sharepoint, file-sharing, etc. > Upgrading to larger disks on the devices can be very costly. In 2011, we > wrote a blog about it. > > Back then, OSD content was indeed large. But back then, one may have been > only managing a few images (.wim)…and that’s it. With Windows 10 as you > know, all of that has changed and many are likely to be managing not only a > few images (and then a .wim for each supported architecture type) but also > the OS Upgrade Package (.iso) content for each Windows 10 edition supported > (and then a .iso for each supported OS architecture type). > > ? OS Image Packages (.wim) for Wipe-n-Load and Refresh scenarios > ? OS Upgrade Packages (.iso) for In-Place Upgrade scenarios > > Take a look at the slide below from a webinar we did last year, as it > explains what the potential is in supporting the minimum total content size > required to support Windows 10 OSD (i.e. minimum total content size, based on > the supported OS editions and architecture types): > > <image002.jpg> > > Not many have the luxury of being guaranteed ~25GB of diskspace for OSD on > each WAN/WAAS/Riverbed device in the environment. What would it cost a > business to upgrade all of the devices so that ~25GB could be guaranteed…just > for OSD? > > You can see that solely relying on WAAS/Riverbed devices for Windows 10 OSD > purposes alone will be a very costly proposition to the business. > > Not trying to sell anything in this reply, but merely attempting to help the > community where we can because “we’ve been there, done that” and want to > bring value by helping to avoid some of the pitfalls. Hopefully, this helps > to build your case for the design being proposed. > > Yes, our goal as a software company is to sell software. But we also want to > help educate the community and industry that we are all so passionate about, > whenever we can. > > This is what 1E is all about J > > Troy L. Martin | Technical Architect > 1E | Software Lifecycle Automation for the Digital Business > US Mobile: +1 (678) 898-6147 | UK Phone : +44 208 326 9141 > [email protected] | www.1e.com > > Facebook | Twitter | YouTube | Blogs | RSS > > From: [email protected] [mailto:[email protected]] > On Behalf Of Jason Wallace > Sent: Wednesday, March 2, 2016 4:58 PM > To: [email protected] > Subject: Re: [mssms] Use of Riverbeds at remote offices > > I guess then Ed it depends upon your definition of "simple" is. > > If "simple" is having to deploy an additional agent to my entire client > estate instead of enabling a feature which is already built into the core OS > then I guess you've got me there. > > If simple is having to update my product using a channel which is not the > base update channel in CM then yup, again you have me. > > I grant you that BranchCache is nowhere near the sophistication that some > peer caching technologies have. > > I'm not trying to convince anyone to buy anything Ed. My brief is to deploy > using out of the box technology where possible and that is what I am doing. I > have a fallback position that I am comfortable with. > > On 2 Mar 2016, at 21:16, Ed Aldrich <[email protected]> wrote: > > “…I am planning on using simple, cheaper and well proven technology” > > Can’t argue cheaper… but simple and well proven, I’d just say that 30million > Nomad licenses over 1700 customers argues nicely for “well proven”. > > …and I’m out. > > Ed Aldrich |Technical Enablement Lead > 1E | Software Lifecycle Automation for the Digital Business > Mobile: (401) 924-2293 > [email protected] | www.1e.com > <image003.png> Ent Client Mgmt MVP (2003-2016) > > From: [email protected] [mailto:[email protected]] > On Behalf Of Jason Wallace > Sent: Wednesday, March 2, 2016 3:26 PM > To: [email protected] > Subject: RE: [mssms] Use of Riverbeds at remote offices > > Thanks John > > This customer is deploying Riverbeds as we speak. > > No, not in the slightest – I am not trying to run a DP on the appliance – > just want to be familiar with what it can offer when it sits between the > small number of DPs that we will be hosting in Azure and the clients which > will largely be running BranchCache. > > Were I to have a branch office scenario where I needed a DP and I couldn’t > have a DP then I would aim to use a peer caching technology (which we are > doing for free) or buy one (in this case, it likely would be a different > product to Nomad) so I am planning on using simple, cheaper and well proven > technology J > > Jason > > From: [email protected] [mailto:[email protected]] > On Behalf Of Marcum, John > Sent: 02 March 2016 19:57 > To: [email protected] > Subject: RE: [mssms] Use of Riverbeds at remote offices > > Jeeze… that post was 5 years ago! Nobody uses Riverbeds anymore. When I did > say that I liked Riverbeds it was only as a WAN accelerator not anything > more. It sounds like you are trying to run a DP on the appliance. If that’s > the case I’m unfamiliar with that use case, probably because as I said…Nobody > uses riverbeds anymore. J > > If I had a branch office scenario where I needed a DP and I couldn’t have a > DP I’d buy nomad and be done with it. That is simple, cheap and well proven > technology. > > > > > > > > John Marcum > MCITP, MCTS, MCSA > Desktop Architect > Bradley Arant Boult Cummings LLP > <image004.png> > <image005.png> > > From: [email protected] [mailto:[email protected]] > On Behalf Of Jason Wallace > Sent: Wednesday, March 2, 2016 10:29 AM > To: [email protected] > Subject: [mssms] Use of Riverbeds at remote offices > > Hi there folks > > I was wondering if someone would have some detail on using Riverbed > Steelheads with CM Agents please? > > We are working on a CM design with DPs at a head office location hosting > BranchCache and clients at remote offices. Between them we have a number of > SteelHeads and I am keen to find out more about how this scenario stands up. > > The customer only supports Riverbedding HTTPS traffic so the assumption is > that we will be supplying the web server certs of the DPs so that they can > get at the data while in transit in order to cache it > > As I have been BinGoogling I have found that Mr Marcum is a fan but Mr Sandys > is not > > https://social.technet.microsoft.com/Forums/systemcenter/en-US/d9ced859-9fe9-4210-9418-3b3f5e02be45/riverbed-scenario?forum=configmgrgeneral > > I also note that RiOS 8.5 introduced support for BranchCache in hosted mode. > Now I know that CM does not support Hosted mode, running in distributed mode > but should the customer implement this does anyone know if the Riverbeds then > publish a service connection point? > > Best Wishes > > Jason > > > > Confidentiality Notice: This e-mail is from a law firm and may be protected > by the attorney-client or work product privileges. If you have received this > message in error, please notify the sender by replying to this e-mail and > then delete it from your computer. > > > > > > Legal Notice: This email is intended only for the person(s) to whom it is > addressed. If you are not an intended recipient and have received this > message in error, please notify the sender immediately by replying to this > email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email > and any attachments may be privileged and/or confidential. The unauthorized > use, disclosure, copying or printing of any information it contains is > strictly prohibited. The opinions expressed in this email are those of the > author and do not necessarily represent the views of 1E Ltd. Nothing in this > email will operate to bind 1E to any order or other contract. > > > > > > Legal Notice: This email is intended only for the person(s) to whom it is > addressed. If you are not an intended recipient and have received this > message in error, please notify the sender immediately by replying to this > email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email > and any attachments may be privileged and/or confidential. The unauthorized > use, disclosure, copying or printing of any information it contains is > strictly prohibited. The opinions expressed in this email are those of the > author and do not necessarily represent the views of 1E Ltd. Nothing in this > email will operate to bind 1E to any order or other contract. > > > > > > > Legal Notice: This email is intended only for the person(s) to whom it is > addressed. If you are not an intended recipient and have received this > message in error, please notify the sender immediately by replying to this > email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email > and any attachments may be privileged and/or confidential. The unauthorized > use, disclosure, copying or printing of any information it contains is > strictly prohibited. The opinions expressed in this email are those of the > author and do not necessarily represent the views of 1E Ltd. Nothing in this > email will operate to bind 1E to any order or other contract. > > > > > > Legal Notice: This email is intended only for the person(s) to whom it is > addressed. If you are not an intended recipient and have received this > message in error, please notify the sender immediately by replying to this > email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email > and any attachments may be privileged and/or confidential. The unauthorized > use, disclosure, copying or printing of any information it contains is > strictly prohibited. The opinions expressed in this email are those of the > author and do not necessarily represent the views of 1E Ltd. Nothing in this > email will operate to bind 1E to any order or other contract. > > > > > > Legal Notice: This email is intended only for the person(s) to whom it is > addressed. If you are not an intended recipient and have received this > message in error, please notify the sender immediately by replying to this > email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email > and any attachments may be privileged and/or confidential. The unauthorized > use, disclosure, copying or printing of any information it contains is > strictly prohibited. The opinions expressed in this email are those of the > author and do not necessarily represent the views of 1E Ltd. Nothing in this > email will operate to bind 1E to any order or other contract. >
