|
Tapedump posted:I’d be better off moving their email hosting to Microsoft (which they like the idea of to get Teams). That wouldn’t help the roaming PST issue any, huh? yes this is the way to go. if you do this then you can do online mode, or just set caching to a really small amount (like locally cache only the last 1 week, everything else online) that will keep it manageable. but really again don't do roaming profiles
|
#
?
Nov 23, 2017 23:40
|
|
|
|
| # ? Apr 23, 2024 10:15 |
|
|
IMAP is just kind of a worn out protocol. In order for “push” to work it has to have a connection open with the server continuously, there are always stupid mailbox sync issues between client and server, depending on how caching/online modes work it can also cause a lot of stress on the server depending on how large mailboxes get, etc. It was fine when everyone had a 500MB ISP mail account or whatever that they accessed irregularly, but now that connections are always-on and everyone expects to be able to keep gigabytes of mail and search it instantly, IMAP is showing its age. I still say go ahead and test roaming profiles. But make sure you do a thorough test. Maybe involve a couple savvy users if they’re willing to be guinea pigs. I think email will be your biggest hurdle. Part of the reason we don’t see issues is that our VDI runs Outlook connected to Exchange in online mode, and we disallow PST’s globally because we have an enterprise email archive. Plus our network storage is fast so VM’s and profiles are loaded very quickly since it’s all within our datacenter network.
|
|
#
?
Nov 24, 2017 06:50
|
|
|
Tapedump posted:My main interest is more with the musical desks game. They currently use Folder Redirection to some success and have most important data on a server share. But, in typical SMB fashion, they've asked if they can hop to any workstation and log in to find their task bar icons, their Outlook client config, etc. the same.
|
|
#
?
Nov 24, 2017 13:37
|
|
|
Start moving your users into the Mail and Calendar active sync apps imo. I don't think Outlook will be a thing by 2020.
|
|
#
?
Nov 24, 2017 13:45
|
|
|
You’re wrong. New version of standalone Office is hitting in 2018.
|
|
#
?
Nov 24, 2017 15:37
|
|
|
Potato Salad posted:I don't think Outlook will be a thing by 2020. quoting for posterity. outlook honestly is the reason i have a brokeback mountain response to microsoft. users expect it, corporate clients require it. nothing interfaces with exchange like it despite very good efforts.
|
|
#
?
Nov 24, 2017 15:53
|
|
|
Potato Salad posted:Start moving your users into the Mail and Calendar active sync apps imo. I don't think Outlook will be a thing by 2020. This is possibly the most wrong post I’ve seen in these threads.
|
|
#
?
Nov 24, 2017 17:47
|
|
|
The Fool posted:This is possibly the most wrong post I’ve seen in these threads. Unfortunately I think you are correct. The Outlook-obsessed won't ever change. They'll always find some obscure feature they don't actually need but they'll convince themselves that alternatives are unusable because it's not there. I'd be a happy man if that pile of poo poo went away, but I'm not holding my breath.
|
|
#
?
Nov 24, 2017 18:22
|
|
|
The Fool posted:This is possibly the most wrong post I’ve seen in these threads. At the very least Exchange will be gone. Which would own.
|
|
#
?
Nov 24, 2017 18:23
|
|
|
Exchange 2018 was already announced.
|
|
#
?
Nov 24, 2017 18:26
|
|
|
Matt Zerella posted:At the very least Exchange will be gone. Which would own. Wtf is wrong with you people. On prem exchange isn’t going anywhere anytime soon either.
|
|
#
?
Nov 24, 2017 18:54
|
|
|
Tapedump posted:You’re right about their PST sizes, mostly. I see how that would be a big fat problem given how you describe profiles roam... e. woops missed a page there. point stands but I'll try to add some actual advice later IMAP is a genuine concern yeah but PSTs are arguably worse. At least, in my experience, might be overreacting but is a measurable percentage of your time related to rebuilding corrupt mail stores? It will once you start roaming profiles on PSTs. That PST and PTSD are nearly anagrams is one of those cosmic coincidences that make me believe the Intelligent Design people have a point Old Binsby fucked around with this message at 21:02 on Nov 24, 2017 |
|
#
?
Nov 24, 2017 20:06
|
|
|
what possible indication do you have that exchange or outlook will die
|
|
#
?
Nov 24, 2017 22:17
|
|
|
Whats this PST business? Don't y'all run into OSTs?
|
|
#
?
Nov 24, 2017 23:23
|
|
|
Matt Zerella posted:At the very least Exchange will be gone. Which would own. This is a reasonable position if you feel email sucks and I agree that it should get its descent into obsolescence over with already. Until then I'd much rather deal with Exchange 2019 (which the SaaS platform will also be based on) than the exim/postfix/dovecot/domino(?)/GoogApps alternatives around. though, while you're waiting for email to die keep in mind people (such as myself) are still out there herding farms of FoIP (yes, Fax-over-IP) gateways. I'm under 30 and I've spent time implementing literally Telex (over SIP) 
|
|
#
?
Nov 25, 2017 01:08
|
|
|
Yes email sucks and I want it to die but I was talking more about on prem exchange which blows rear end and I'm fine with Google/365 taking over there as long as there's no legal requirement for on prem. I mainly deal with small shops and I push every time to get people to get rid of their lovely rear end old on prem setup whenever possible.
|
|
#
?
Nov 25, 2017 02:02
|
|
|
At work we're making the move to Our Corporate Overlord's thin client system. We're going to: Drop backups of user systems. Push everyone to Google Drive; the parent org has been mapping a U: drive for the logged-in user by policy for ages. Roll out a system that syncs personal stuff like bookmarks and mapped drives. The model is, your laptop breaks and you log into a spare, all your stuff syncs. No more data transfer. The whole concept of a loaner transforms. I think it's going to be great. Google certainly will be happy, globally we're six figures for users. It really is Bill Gates' Netscape Nightmare finally come to life.
|
|
#
?
Nov 25, 2017 02:33
|
|
|
redeyes posted:Whats this PST business? Don't y'all run into OSTs? OSTs is for online cache of exchange mailbox but they're talking about IMAP from gmail so it would use a PST
|
|
#
?
Nov 25, 2017 03:37
|
|
|
NevergirlsOFFICIAL posted:OSTs is for online cache of exchange mailbox but they're talking about IMAP from gmail so it would use a PST FWIW, outlook 2013+ uses ost for imap too
|
|
#
?
Nov 25, 2017 04:46
|
|
|
The Fool posted:FWIW, outlook 2013+ uses ost for imap too oh, huh. well now you know when the last time I used outlook with imap was
|
|
#
?
Nov 25, 2017 13:30
|
|
|
We have an Exchange 2016 DAG and it works great. Zero issues and have not had to gently caress with it much ever. Basically have had zero problems with on prem Exchange since migrating from GroupWise in 2008. We also block all PST's via a GPO and don't allow mailboxes larger than 2 gigs and no attachments over 5 megs.
|
|
#
?
Nov 25, 2017 17:57
|
|
|
My bad, I use PST and OST interchangeably even though I know they're not the same thing. In either case, the need for Roaming Profiles to move around large Outlook data stores is a big bog-down point is what I'm hearing.
|
|
#
?
Nov 25, 2017 18:22
|
|
|
I (almost) landed a project gig for making some developers network IPv6 ready so that their internal app can be distributed by the Apple app store. Supposedly, the ISP has to provision them an IPv6 account (or something?) and then I can test their internally hosted server by using something like ipv6-test.com. Their internal network has to also support IPv6 (presumably?) and there's an app store developer site that goes into detail on how to test that, but that may be out of scope for this project. Can someone please tell me what I'm missing? I haven't had to deal with IPv6 or app store apps yet and I don't know what I don't know.
|
|
#
?
Dec 10, 2017 00:26
|
|
|
Your ISP needs to support IPv6 - most of the large consumer ISPs do already since they supply their own routers and are good at doing it pretty seamlessly now. The smaller ISPs tend to either go all-in on IPv6 and have supported it for years, or are ignoring it. If your provider doesn't do IPv6 then you could either use a 6to4 tunnel, or just get a connection from somebody that does do IPv6. And it needs configuring on your internal network. If you are a business and are served by a commercial ISP then it's probably worth getting your own allocation of IPv6 (either a Provider Independent block or an AS number depending on how your RIR tackles this) so you can take them with you or multihome in future, since it affects internal addressing now that NAT is going away.
|
|
#
?
Dec 10, 2017 10:48
|
|
|
If your ISP can't help, you can get IPv6 over a tunnel from Hurricane Electric for free https://tunnelbroker.net/ The decreased MTU will occasionally make your life interesting.
|
|
#
?
Dec 10, 2017 14:55
|
|
|
thebigcow posted:If your ISP can't help, you can get IPv6 over a tunnel from Hurricane Electric for free https://tunnelbroker.net/ Warning for anyone wanting to use this at home, Netflix will prefer IPv6 and try to run over this. That used to just cause occasional performance issues but for the last year or two Netflix has just straight up blocked traffic from Hurricane's tunnel networks because they can be used to bypass geolocation. I pretty much had to block the entirety of AWS over IPv6 to get Netflix to run over my native IPv4 connection.
|
|
#
?
Dec 10, 2017 18:01
|
|
|
Youtube used to ignore MTU and just break outright.
|
|
#
?
Dec 10, 2017 19:52
|
|
|
RDS research question: How do workstation/clients actually use the Remote Desktop Services (session-based) a server provides? As in, what are the steps needed to make a workstation use this? Is it join to domain, log in as domain UserX, and the server does all the magic? Login as domain UserX and the open the RDC client? Or, do users have to hit the Remote App and Desktop Connections webpage first? I'm finding loads of info on Server 2008, less on 2012, and very little on 2016, but none of what I've found goes over the steps of "Here's a workstation, so do this to make it work." It would be great if you would answer as if I'm a bit dense (about this). I know it assumes such knowledge, but as with much IT an initial step isn't obvious right up until it is. (Interested in full desktops that "follow" a user despite machine, not RemoteApp, etc.) Am I off base in thinking that session-based RDS can pretty much offer the same experience for my users as VDI and rolling a VM for each person? I was hoping to avoid the cost of hardware needed to VDI 15-25 people. Tapedump fucked around with this message at 00:38 on Dec 18, 2017 |
|
#
?
Dec 18, 2017 00:32
|
|
|
Depends on your scenario, but generally you just open up a remote desktop session to the remote desktop session host and that's their workspace.
|
|
#
?
Dec 18, 2017 17:57
|
|
|
Thank you! Ah, so it takes user login to domain account on workstation, and then RDC is used to connect. Gotcha. Meaning, it’s not as seemless-looking to the user as a “regular” login, as one needs to login to the physical workstation and then again in RDC, right? Or is it...? Could some of this RDC connection could be automated? Now that I know that this ultimately presents an RDC session once a user has logged into a workstation with a domain account, rather than superimposing magic somehow, that’s very helpful to comprehension. Does a properly set up RDS system require additional steps by the user to get to one’s RDS session on the host beyond logging in to domain account at physical machine? I’d like to try testing this out with a trial of Server 2016 or a copy of 2012 with a bunch of dummy workstations (mix of VM and physical), so I’m looking out for that point where I can “see” it working and know I’m on the right track. (Right track on this research... it may be the wrong track for my actual purposes, but I’m keen to chase those down first for my own knowledge. I’m not opposed to pragmatism, though.)
|
|
#
?
Dec 18, 2017 18:29
|
|
|
You could set up your workstations to autologin as a locked down user account with a single shortcut to connect to the RDS server on the desktop/taskbar/start menu labeled "LOG IN" and train your users to click it. That would be fairly seamless.
|
|
#
?
Dec 18, 2017 18:40
|
|
|
SamDabbers posted:You could set up your workstations to autologin as a locked down user account with a single shortcut to connect to the RDS server on the desktop/taskbar/start menu labeled "LOG IN" and train your users to click it. That would be fairly seamless. This is how a lot of thin clients work. To make it even smoother, you can set the RDP session to launch automatically.
|
|
#
?
Dec 18, 2017 18:43
|
|
|
You can also publish applications to RDS so they open up the program and it looks like they opened it up on their computer but it's running on the remote server. This can become a pain if they are doing a bunch of printing since they are bringing printers into the session and if they need to change default printer settings they need to open up the control panel on the server. Which is likely going to cause confusion in most users, it does to mine! I haven't had time to try it yet but I had an idea to deploy control panel or the printers and devices section of control panel at least, so they could click that on their desktop to change the printer settings on the server. I'm not even sure it's possible. Overall I think it's a better smoother experience to publish the app download it yourself and throw it on the desktop like any other rdp shortcut.
|
|
#
?
Dec 18, 2017 18:46
|
|
|
Thank you all, I'm getting it more now! I setup a trial of 2016 and installed the RDS role to experiment with. Now that I see how the "first user step" can be handled, it makes much more sense. Odd I thought, though, that even a workstation not joined to the domain can use RDC to access $servername at $domain\$username with just the proper creds. I suppose that can/ought to be limited to domain-joined machines, right?
|
|
#
?
Dec 19, 2017 03:57
|
|
|
Tapedump posted:Odd I thought, though, that even a workstation not joined to the domain can use RDC to access $servername at $domain\$username with just the proper creds. I suppose that can/ought to be limited to domain-joined machines, right? I'm honestly not sure if there's even a way to only allow domain-joined machines to make a connection. I've never seen a setup like that. (It would make life a little hard on all of us sysadmins with Macbooks.) Of course, I only ever use RDP for server administration for our legacy Windows stuff. The requirements could be completely different if you're using it to give users their everyday desktop, like you're describing.
|
|
#
?
Dec 19, 2017 05:10
|
|
|
Tapedump posted:Thank you all, I'm getting it more now! I setup a trial of 2016 and installed the RDS role to experiment with. You can have non domain machines use domain\user if you can get them to type that. We have some people with personal laptop use it for remote access after they VPN. One thing is you may need a self signed cert. If you don't own your domain say you are using .local or have it just as a domain someone else owns because that's the first 4 letters of the company. You will have to tell your non domain users how to install the cert, which is just have them open it and install it to their user trusted root. This just works on a domain joined PC or if you actually own the domain and get it a public cert it just works. If everything is domain joined go ahead and lock it down if you don't have a use case.
|
|
#
?
Dec 19, 2017 10:54
|
|
|
Powered Descent posted:I'm honestly not sure if there's even a way to only allow domain-joined machines to make a connection. I've never seen a setup like that. (It would make life a little hard on all of us sysadmins with Macbooks.) Windows firewall can filter on Active Directory objects, and also force things over IPsec if you set up the infrastructure first. It's always an option if your application offers no other means.
|
|
#
?
Dec 19, 2017 18:00
|
|
|
I never thought about non-domain joined computers, Macs or otherwise, connecting to the server like that. Interesting. That also makes me realize that I could take this trial 2016 box down to their shop to "demo" it (in a very simplistic way). Since I can RDC into the server from my gaming PC without it being joined the domain, so could X number of their own office workstations. I didn't need to use domain\user, either. Weird?  To that end, would you point me in the right direction on how to change this behavior? I'm pretty sure I can get them to adopt any new logon procedure, but I'd like to learn about securing this, too. Group policy stuff? Starting point? Regarding certs, they own a .com domain but it's 19 characters long. I loathe to have to type it in over and over. Is it wise to use a different, shorter one for their AD domain?
|
|
#
?
Dec 19, 2017 18:20
|
|
|
So we had a client get hit with WannaCry. The backup solution they had us put in was trash but thankfully they only lost a week before we could stop it. We're attempting to find a decent open source backup solution that would let us manage multiple servers from a single interface. Does anything like that exist? We've been looking around but have had difficulties separating the wheat from the chaff.
|
|
#
?
Dec 20, 2017 16:17
|
|
|
|
| # ? Apr 23, 2024 10:15 |
|
|
I had done some testing with Amanda at a previous job, but never put it in production: http://amanda.zmanda.com
|
|
#
?
Dec 20, 2017 16:22
|
|