No it's not.
________________________________
John Marcum
MCITP, MCTS, MCSA
Desktop Architect
Bradley Arant Boult Cummings LLP
________________________________
[MVP] <https://mvp.microsoft.com/en-us/overview>
[MMS] <http://mmsmoa.com/>
From: [email protected] [mailto:[email protected]] On
Behalf Of Michael Mott
Sent: Thursday, March 3, 2016 10:22 AM
To: [email protected]
Subject: RE: [mssms] Use of Riverbeds at remote offices
Is de-dupe OFFICIALLY supported on Enterprise desktop OS's yet?
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Phil Wilcock
Sent: Thursday, March 03, 2016 10:04 AM
To: [email protected]<mailto:[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 :)
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 :)
See you at MMS Mr Martin!
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Troy Martin
Sent: 03 March 2016 13:43
To: [email protected]<mailto:[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>
[Image removed by sender.
https://pbs.twimg.com/profile_images/1498237153/arwidmark_normal.jpg]
Johan Arwidmark (@jarwidmark<https://twitter.com/jarwidmark?refsrc=email&s=11>)
3/2/16, 11:18
PM<https://twitter.com/jarwidmark/status/705245944598532096?refsrc=email&s=11>
In the POC lab, pushing 25 GB images to 442 laptops in a distributed
environment using SCCM and @1E_Global<https://twitter.com/1E_Global>
pic.twitter.com/yxuulxQs2I<https://t.co/yxuulxQs2I>
1E | Software Lifecycle Automation
On Mar 3, 2016, at 6:46 AM, Andreas Hammarskjöld
<[email protected]<mailto:[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]>
[mailto:[email protected]] On Behalf Of Phil Wilcock
Sent: den 3 mars 2016 08:55
To: [email protected]<mailto:[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]>
[mailto:[email protected]] On Behalf Of Troy Martin
Sent: 02 March 2016 23:00
To: [email protected]<mailto:[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<http://www.1e.com/blogs/2011/11/22/nomad-enterprise-eliminates-the-need-for-costly-wan-optimization-device-upgrades/>.
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<http://www.1e.com/turbocharge-your-windows-10-migration-with-nomad-6-0/>,
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 :)
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]<mailto:[email protected]> |
www.1e.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.1e.com_&d=BQMFAg&c=Ln8c1CLEgbhz4W2FGOnrXYpHvIYN4k_cXHVmsANM4XI&r=zAhc69MwvUId2afOheLZsnttbIFqxDANe5KRT-ZKir4&m=uHdy6p01-w9GZjdBVTraJ5PHeWP6yKoA_xCBrm33uC4&s=lfm9K0cSqM44FHIoBa6p0wzT4MWYkn_0HYGNmWgkATs&e=>
Facebook<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_1eglobal&d=BQMFAg&c=Ln8c1CLEgbhz4W2FGOnrXYpHvIYN4k_cXHVmsANM4XI&r=zAhc69MwvUId2afOheLZsnttbIFqxDANe5KRT-ZKir4&m=uHdy6p01-w9GZjdBVTraJ5PHeWP6yKoA_xCBrm33uC4&s=RRWJDZaMGcmivktB58TkvRLoQr1bC6jIDj-MN1oDLlE&e=>
|
Twitter<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_1e-5Fglobal_&d=BQMFAg&c=Ln8c1CLEgbhz4W2FGOnrXYpHvIYN4k_cXHVmsANM4XI&r=zAhc69MwvUId2afOheLZsnttbIFqxDANe5KRT-ZKir4&m=uHdy6p01-w9GZjdBVTraJ5PHeWP6yKoA_xCBrm33uC4&s=6SY99zYqJ1R5pAavjFi-JmFdxUD0lt-n0XwOK-omJcI&e=>
|
YouTube<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.youtube.com_1enews&d=BQMFAg&c=Ln8c1CLEgbhz4W2FGOnrXYpHvIYN4k_cXHVmsANM4XI&r=zAhc69MwvUId2afOheLZsnttbIFqxDANe5KRT-ZKir4&m=uHdy6p01-w9GZjdBVTraJ5PHeWP6yKoA_xCBrm33uC4&s=XWjlpxF0vI8J3n42uqWMrEXgHphlWI2PD9XZHOHhX8U&e=>
|
Blogs<https://urldefense.proofpoint.com/v2/url?u=http-3A__blogs.1e.com_&d=BQMFAg&c=Ln8c1CLEgbhz4W2FGOnrXYpHvIYN4k_cXHVmsANM4XI&r=zAhc69MwvUId2afOheLZsnttbIFqxDANe5KRT-ZKir4&m=uHdy6p01-w9GZjdBVTraJ5PHeWP6yKoA_xCBrm33uC4&s=tKrxeysyE64idSmjz1G3NP2ojp9RhRdpv1OljUgTbyg&e=>
|
RSS<https://urldefense.proofpoint.com/v2/url?u=http-3A__blogs.1e.com_index.php_feed_&d=BQMFAg&c=Ln8c1CLEgbhz4W2FGOnrXYpHvIYN4k_cXHVmsANM4XI&r=zAhc69MwvUId2afOheLZsnttbIFqxDANe5KRT-ZKir4&m=uHdy6p01-w9GZjdBVTraJ5PHeWP6yKoA_xCBrm33uC4&s=qGt8-ZGt5rG-J3ClWoppG9TfmFKmktUZprrf0vtNjII&e=>
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Jason Wallace
Sent: Wednesday, March 2, 2016 4:58 PM
To: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> | www.1e.com<http://www.1e.com/>
<image003.png> Ent Client Mgmt MVP (2003-2016)
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Jason Wallace
Sent: Wednesday, March 2, 2016 3:26 PM
To: [email protected]<mailto:[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 :)
Jason
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Marcum, John
Sent: 02 March 2016 19:57
To: [email protected]<mailto:[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. :)
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><https://mvp.microsoft.com/en-us/overview>
<image005.png><http://mmsmoa.com/>
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Jason Wallace
Sent: Wednesday, March 2, 2016 10:29 AM
To: [email protected]<mailto:[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.